8000 Upon PR closure, only reintegrate later pull requests if it is integrated by rudymatela · Pull Request #177 · channable/hoff · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

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

Merged
merged 3 commits into from
Aug 24, 2022

Conversation

rudymatela
Copy link
@rudymatela rudymatela commented Aug 24, 2022

Closes: #161

Upon PR closure, only reintegrate later pull requests if it is integrated.

  1. A new test was added to assure that this case was caught. The build fails ❌ on the first commit as proof of this;
  2. The behaviour of 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.

@rudymatela rudymatela self-assigned this Aug 24, 2022
@rudymatela rudymatela added bug Something isn't working OKR Objectives and Key Results train Involves Merge Trains labels Aug 24, 2022
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.
@rudymatela rudymatela requested review from fatho and xrvdg August 24, 2022 12:42
@rudymatela
Copy link
Author

This is ready for review.

@fatho and @xrvdg, can either of you please take a look? (First-come-first-merged 😜)

This is a bug that is live in production and can introduce some merge delays. If I manage to merge this today, I can try to deploy tomorrow morning.

Copy link
Member
@fatho fatho left a 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
Copy link
Member

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?

Copy link
Author

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 of master
  • testing/2 is integrated on top of testing/1
  • testing/3 is integrated on top of testing/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.)

Copy link
Author

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.

@rudymatela rudymatela removed the request for review from xrvdg August 24, 2022 15:18
@rudymatela
Copy link
Author

@OpsBotPrime merge

@OpsBotPrime
Copy link

Pull request approved for merge by @rudymatela, rebasing now.

@rudymatela
Copy link
Author

@fatho Thanks for the review!

…it is integrated

Approved-by: rudymatela
Auto-deploy: false
@OpsBotPrime
Copy link

Rebased as 772ab26, waiting for CI …

@OpsBotPrime
Copy link

CI job 🟡 started.

@OpsBotPrime OpsBotPrime merged commit 772ab26 into master Aug 24, 2022
@OpsBotPrime OpsBotPrime deleted the fix-avoid-uneeded-rebase branch August 24, 2022 15:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working OKR Objectives and Key Results train Involves Merge Trains
Projects
None yet
Development

Successfully merging this pull request may close these issues.

fix double rebase with single merge command
3 participants
0