-
Notifications
You must be signed in to change notification settings - Fork 166
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
git-open-pr : "Another open merge request already exists for this source branch" : retrieve the ID of the MR/PR and go next step #2845
Comments
same on 0.9.1 |
@hiddeco, give me a sanity check? The legacy promo mechs in v0.9.x and earlier used to store the promotion number in the Promotion's bygone For reference: kargo/internal/controller/promotion/git.go Lines 218 to 223 in e746b7b
We currently have no equivalent to this check in the Promotion steps only repeat themselves if we're forced to start a Promotion over from the beginning because we lost its working directory -- which would pretty much only be because the controller restarted while the Promotion was in-progress. You can see this right here: kargo/internal/controller/promotions/promotions.go Lines 463 to 480 in c462c76
You'll notice we clear the shared state if we determine we're starting over. If we reset the starting step back to zero, but don't clear the shared state right here, the I cannot think of any reason not to make this change, but as I said... I wanted a quick sanity check. lmk |
I think there are two scenarios we need to consider:
I agree with not clearing the shared state initially during step zero resets. But once the process has started, I have concerns about ending up with a mixed bag of "previous" and "new" attempted state, which arguably can be misleading in certain scenarios. An alternative to address this would be to determine if any garbage collection / finalization needs to happen based on the existing state, which would allow you to e.g. close the pull request and/or delete the branch before kickstarting a new promotion. If we decide to find existing branches / pull requests / merge requests, we must enforce the state of the branch to match the Promotion steps' output. |
Well... that's my mistake. Precisely because state can reset, I wanted to be sure we could deterministically derive a PR's head branch name. Why I based that on Project and Stage names instead of Promotion names... I can't say where my head was at in that moment. I will happily fix this.
I did think about that, but convinced myself that because steps are ordered, as long as state returned from any step overwrites state it returned from a previous execution, then everything any subsequent step might refer to is guaranteed to be based on fresh state. So I think any confusion would be limited to human confusion, but if you were ever to see state from a step greater than the current step, it would be obvious what had happened.
Agree. And that would mostly happen naturally. If the first run through pushed to branch x and opened PR 42, the second run through would push to branch x (if there were any diffs) and leave PR 42 alone. Edit: The only reason to update the PR may be if the title/body had changed for any reason. Edit 2: I think it's both easier and, more importantly, more straightforward to "reclaim" branches and PRs from a previous execution than to garbage collect. |
In Kargo Render it was possible to either open a new PR or add to an existing PR that was already open for the Rendered Manifest Pattern branch. This is useful if the PR identifies an issue that needs to be fixed before the PR can be approved. It doesn't appear as if Kargo (v1.0.3) offers a similar option. From what I can tell, if a PR is opened by Kargo and then a new promotion is started to that stage from the same warehouse then the second promotion waits and does not start executing (refer image below). Does this ticket refer to a scenario where the second promotion would be allowed to proceed to add the commits into the PR from the first promotion or is this ticket a completely different scenario? |
With promotion mechanisms stage with PR promotion doesn't have PR icon (at least in 0.9) and any other differences from stages without PR promotion. It can be hard to understand at all for user that PR is created and should me merged somewhere |
I think that this has been fixed in Kargo v1.0.3 (refer first image below). The first stage has the In my comment above, I initiated another promotion while the original promotion was waiting for the open PR to be merged which led to the second promotion being queued. I left the PR open overnight (and it remains open) but both the active and pending promotion pipelines have now failed with the following message (refer second screenshot below):
This may be intended behaviour of Kargo but I wanted to mention it as it continues from my comment above. It does highlight though that PRs must be processed fairly quickly after being created by Kargo. |
Hi, |
Checklist
kargo version
, if applicable.Proposed Feature
When a MR is already opened retrieve it's ID and continue with next step
Motivation
Stage is failing but it should not
The text was updated successfully, but these errors were encountered: