HN Explorer

10 comments

[ 4.2 ms ] story [ 32.4 ms ] thread
gus_massa
Does it rebase the PR to keep a linear history?
toomuchtodo
This is brilliant from a release engineering/continuous integration perspective. Kudos to the folks who delivered this.
ditsuke
So, mergify built in?
jd__
Rather 1/5th of Mergify, and still in beta, but that's the spirit yes. :)

(Julien from Mergify)

kadoban
So 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.
[deleted]
(comment deleted)
remram
What 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?
TheCoelacanth
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.

[1] https://github.com/bors-ng/bors-ng

jd__
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)

[deleted]
(comment deleted)