-
Notifications
You must be signed in to change notification settings - Fork 27
[DNM] alternate implementation of servicing abort for BMO #431
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
/hold |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: rhjanders The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
59c1c10 to
cf0df59
Compare
fad302d to
bb35cb4
Compare
306e5f7 to
655cd00
Compare
This change addresses the issue of lack of clear pathway from recovering from a failed servicing operation. If serivcing operation is in progress or in the failed state and the user adjusts hfs.spec and/or hfc.spec (or removes the specs entirely) to ensure that ChangeDetected condition becomes false, servicing is aborted. Generated-By: Claude Code Sonnet 4 Signed-off-by: Jacob Anders <janders@redhat.com>
2c8ec32 to
325ee71
Compare
This change resolves the issue where removing hfc.spec results in ChangeDetected condition being set to True in case status.updates field is also present Assisted-By: Claude Code Sonnet 4 Signed-off-by: Jacob Anders <janders@redhat.com>
325ee71 to
de007d3
Compare
694122e to
9f86944
Compare
|
@rhjanders: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
hmm this didn't quite work, uncommanded abort still occured: To be investigated further |
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
No description provided.