Skip to content
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

Set up merge bot for repository #491

Open
celskeggs opened this issue Feb 14, 2020 · 4 comments · Fixed by #511
Open

Set up merge bot for repository #491

celskeggs opened this issue Feb 14, 2020 · 4 comments · Fixed by #511

Comments

@celskeggs
Copy link
Member

celskeggs commented Feb 14, 2020

You know what's annoying? Having to manually rebase every PR, often multiple times, before it be can merged.

As suggested by @cryslith, let's set up Bors-NG. This will allow us to adjust our workflow to stop being based in rebasing everything -- which is somewhat easy for new contributors to get wrong, beyond being a waste of valuable developer time.

@cryslith
Copy link
Member

Unfortunately bors only supports merge and squash-merge, not rebasing right now, as we currently use.

@celskeggs
Copy link
Member Author

As long as we only use merge commits to merge into master, and never use them for conflict resolution, I would be okay with us switching to a system where we use merge commits in a limited fashion.

i.e.

  • Before you can submit your PR to the bot for evaluation and merge, you have to:
    • rebase away any "fix [...]" commits or similar
    • rebase against a recent enough version of master that there are no merge conflicts
    • ensure that there are no merge commits in your branch
  • Once you get approval from a reviewer, you can submit your PR to the bot (bors r+ mode) -- or the reviewer can do that for you when they approve, if you checked our "ready to merge" box.
  • The bot does its testing dance to ensure that your PR -- and any others ready at the same time -- don't conflict, and then merges them into master with an explicit merge commit.

This way, instead of a single linear history, we would have a history with only simple branching. This would still be reasonably easy to bisect and interpret after the fact.

I would also be fine with us finding an alternative that works with rebasing. I am also a fan of the gerrit model where you review and verify individual commits in a PR, and can press a button to cherry-pick them onto master one commit at a time.

What do you think?

@cryslith
Copy link
Member

Sounds fine to me :)

@cryslith cryslith self-assigned this Apr 18, 2020
@cryslith cryslith mentioned this issue Apr 19, 2020
11 tasks
hyades-bors bot pushed a commit that referenced this issue Apr 20, 2020
511: Add bors-ng configuration r=celskeggs a=cryslith

- Configure bors-ng
- Run CircleCI only during bors merges
- Require branches to have linear git history

Closes #491.



Co-authored-by: Lily Chung <[email protected]>
hyades-bors bot pushed a commit that referenced this issue Apr 21, 2020
511: Add bors-ng configuration r=cryslith a=cryslith

- Configure bors-ng
- Run CircleCI only during bors merges
- Require branches to have linear git history

Closes #491.



Co-authored-by: Lily Chung <[email protected]>
@hyades-bors hyades-bors bot closed this as completed in ced57ff Apr 21, 2020
@cryslith cryslith reopened this Apr 24, 2020
@cryslith
Copy link
Member

We've decided to go with our own homegrown solution to this, so we can use cherry-picking and also for general stability/quality.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants