4 ms·

Pull request merge queue (public beta)

• deleted 4y ago
  [deleted]
• gus_massa 4y ago
  Does it rebase the PR to keep a linear history?
• toomuchtodo 4y ago
  This is brilliant from a release engineering/continuous integration perspective. Kudos to the folks who delivered this.
• ditsuke 4y ago
  So, mergify built in?
  • jd__ 4y ago
    Rather 1/5th of Mergify, and still in beta, but that's the spirit yes. :) (Julien from Mergify)
• kadoban 4y ago
  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.
• remram 4y ago
  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 4y ago
    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 https://github.com/bors-ng/bors-ng
  • jd__ 4y ago
    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 4y ago
      [deleted]