Pull request merge queue (public beta)
github.blog
Pull request merge queue (public beta)
1–10 of 11 posts
Re: Pull request merge queue (public beta)
#2Does it rebase the PR to keep a linear history?
Re: Pull request merge queue (public beta)
#3This is brilliant from a release engineering/continuous integration perspective. Kudos to the folks who delivered this.
Re: Pull request merge queue (public beta)
#4So, mergify built in?
Re: Pull request merge queue (public beta)
#5So far my experience with this is that I have to dismiss it (the "hey you should try this!" popup) for every single repository that I view, really quite obnoxious.
Re: Pull request merge queue (public beta)
#6[deleted]
Re: Pull request merge queue (public beta)
#7So, mergify built in?
Rather 1/5th of Mergify, and still in beta, but that's the spirit yes. :)
(Julien from Mergify)
Re: Pull request merge queue (public beta)
#8What if you still have too many pull requests per day, compared to the time it takes to run CI? For example if you get 10 PRs a day but CI takes 3 hours?
Re: Pull request merge queue (public beta)
#9What if you still have too many pull requests per day, compared to the time it takes to run CI? For example if you get 10 PRs a day but CI takes 3 hours?
Not sure if this does the same thing, but bors[1], another implementation of this concept, will batch together multiple PRs into a single CI run and follow a git-bisect-like workflow to identify the bad PR if a batch fails.
Re: Pull request merge queue (public beta)
#10What if you still have too many pull requests per day, compared to the time it takes to run CI? For example if you get 10 PRs a day but CI takes 3 hours?
Best way is to batch your PRs in a single CI run. That saves CI time and increase your throughput.
It does not seem GitHub merge queue supports this, but some merge queues do support this.
(Julien from Mergify)