-
Notifications
You must be signed in to change notification settings - Fork 4
Upon PR closure, only reintegrate later pull requests if it is integrated #177
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
Conversation
... other PRs in the train
Before an early PR closure (or new commit) had the power to unintegrate PRs in the train, regardless if this PR was integrated or not! The unintegration of later PRs should only happen when the PR being closed has been integrated and thus is the base for these following PRs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks correct to me.
@@ -380,9 +380,10 @@ handlePullRequestClosed closingReason pr state = do | |||
-- actually delete the pull request | |||
pure . Pr.deletePullRequest pr | |||
$ case Pr.lookupPullRequest pr state of | |||
Just (Pr.PullRequest{Pr.integrationStatus = Promoted}) -> state | |||
-- we unintegrate PRs after it if it has not been promoted to master | |||
_ -> unintegrateAfter pr $ state |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What would "after" even mean if a PR wasn't integrated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hoff's internal terminology is a bit confusing:
- integrated mean: a
testing/123
branch has been created with a rebase and merge commit - promoted means: the merge commit sha has been pushed to be the new master
So integrated after it means the further testing branches, e.g.:
testing/1
is integrated on top ofmaster
testing/2
is integrated on top oftesting/1
testing/3
is integrated on top oftesting/2
What we want to do here with unintegrateAfter
is, for example, supposing PR#2 is closed. To "unintegrate" testing/3
so it is scheduled to be integrated on top of testing/1
(assuming the build of PR#1 has not been concluded)
(But sometimes, sometimes, integrated is used to mean promoted. I should probably hunt these cases and make the terminology more consistent later.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What would "after" even mean if a PR wasn't integrated?
Yes, exactly! So we end up restarting the builds "randomly" because an unintegrated PR received a new push.
@OpsBotPrime merge |
Pull request approved for merge by @rudymatela, rebasing now. |
@fatho Thanks for the review! |
…it is integrated Approved-by: rudymatela Auto-deploy: false
Rebased as 772ab26, waiting for CI … |
CI job 🟡 started. |
Closes: #161
Upon PR closure, only reintegrate later pull requests if it is integrated.
handlePullRequestClosed
was fixed. The build passes ✔️ on the second commit.Before an early PR closure (or new commit) had the power to unintegrate PRs in the train, regardless if this PR was integrated or not! The unintegration of later PRs should only happen when the PR being closed has been integrated and thus is the base for these following PRs.