Add hot loop test automation#6212
Conversation
|
Pipeline controller notification For optional jobs, comment This repository is configured in: LGTM mode |
WalkthroughIn ChangesBootimage test updates
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 11 | ❌ 4❌ Failed checks (4 warnings)
✅ Passed checks (11 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sergiordlr The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@test/extended-priv/mco_bootimages.go`:
- Around line 727-730: The failure message format strings in the assertion calls
contain two %s placeholders each, but only one argument
(machineConfiguration.PrettyString()) is provided to each. This causes Go's
formatter to output %!s(MISSING) in the diagnostics, making debugging harder.
Fix both assertions by either removing the second %s placeholder from each
format string or providing an appropriate second argument to match the number of
placeholders. This issue appears in the block around lines 727-730 and also
applies to similar assertions around lines 746-747.
- Line 703: The `defer clonedMS.Delete()` statement ignores the error returned
by the Delete() method, which violates Go coding guidelines and can cause
resource leaks in this disruptive test. Modify the deferred cleanup to capture
and explicitly handle the error returned by clonedMS.Delete() - this typically
involves logging the error or checking it to ensure cleanup failures are not
silently ignored and can be traced during test debugging.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 1a678e5f-7091-4947-89b3-08083ff82315
📒 Files selected for processing (1)
test/extended-priv/mco_bootimages.go
| exutil.By("Clone the first machineset") | ||
| clonedMS, err := machineSet.Duplicate(clonedMSName) | ||
| o.Expect(err).NotTo(o.HaveOccurred(), "Error duplicating %s", machineSet) | ||
| defer clonedMS.Delete() |
There was a problem hiding this comment.
Handle deferred cleanup errors explicitly.
defer clonedMS.Delete() ignores the returned error (Line 703). In this disruptive test, failed cleanup can leak resources and cause cross-test instability.
Suggested fix
- defer clonedMS.Delete()
+ defer func() {
+ o.Expect(clonedMS.Delete()).To(o.Succeed(), "Failed to delete cloned machineset %s", clonedMSName)
+ }()As per coding guidelines, Go code should never ignore error returns.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| defer clonedMS.Delete() | |
| defer func() { | |
| o.Expect(clonedMS.Delete()).To(o.Succeed(), "Failed to delete cloned machineset %s", clonedMSName) | |
| }() |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@test/extended-priv/mco_bootimages.go` at line 703, The `defer
clonedMS.Delete()` statement ignores the error returned by the Delete() method,
which violates Go coding guidelines and can cause resource leaks in this
disruptive test. Modify the deferred cleanup to capture and explicitly handle
the error returned by clonedMS.Delete() - this typically involves logging the
error or checking it to ensure cleanup failures are not silently ignored and can
be traced during test debugging.
Source: Coding guidelines
| "Expected %s to be BootImageUpdateDegraded due to hot loop.\n%s", machineConfiguration.PrettyString()) | ||
|
|
||
| o.Eventually(machineConfiguration, "5m", "20s").Should(HaveConditionField("BootImageUpdateDegraded", "message", o.MatchRegexp(expectedHotLoopMessageRegex)), | ||
| "Expected hot loop error message in %s.\n%s", machineConfiguration.PrettyString()) |
There was a problem hiding this comment.
Fix assertion format strings with missing arguments.
These failure messages use two %s placeholders but pass one argument, so diagnostics will contain %!s(MISSING) and be harder to debug.
Suggested fix
- o.Eventually(machineConfiguration, "5m", "20s").Should(HaveConditionField("BootImageUpdateDegraded", "status", "True"),
- "Expected %s to be BootImageUpdateDegraded due to hot loop.\n%s", machineConfiguration.PrettyString())
+ o.Eventually(machineConfiguration, "5m", "20s").Should(HaveConditionField("BootImageUpdateDegraded", "status", "True"),
+ "Expected BootImageUpdateDegraded=True due to hot loop.\n%s", machineConfiguration.PrettyString())
- o.Eventually(machineConfiguration, "5m", "20s").Should(HaveConditionField("BootImageUpdateDegraded", "message", o.MatchRegexp(expectedHotLoopMessageRegex)),
- "Expected hot loop error message in %s.\n%s", machineConfiguration.PrettyString())
+ o.Eventually(machineConfiguration, "5m", "20s").Should(HaveConditionField("BootImageUpdateDegraded", "message", o.MatchRegexp(expectedHotLoopMessageRegex)),
+ "Expected hot loop error message.\n%s", machineConfiguration.PrettyString())
- o.Eventually(machineConfiguration, "5m", "20s").Should(HaveConditionField("BootImageUpdateDegraded", "status", "False"),
- "Expected %s NOT to be BootImageUpdateDegraded after clearing hot loop.\n%s", machineConfiguration.PrettyString())
+ o.Eventually(machineConfiguration, "5m", "20s").Should(HaveConditionField("BootImageUpdateDegraded", "status", "False"),
+ "Expected BootImageUpdateDegraded=False after clearing hot loop.\n%s", machineConfiguration.PrettyString())Also applies to: 746-747
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@test/extended-priv/mco_bootimages.go` around lines 727 - 730, The failure
message format strings in the assertion calls contain two %s placeholders each,
but only one argument (machineConfiguration.PrettyString()) is provided to each.
This causes Go's formatter to output %!s(MISSING) in the diagnostics, making
debugging harder. Fix both assertions by either removing the second %s
placeholder from each format string or providing an appropriate second argument
to match the number of placeholders. This issue appears in the block around
lines 727-730 and also applies to similar assertions around lines 746-747.
- What I did
WIP
- How to verify it
- Description for the changelog
Summary by CodeRabbit
Release Notes