On Wed, Feb 3, 2021 at 9:14 AM Damien Duportal <[email protected]> wrote:
> > - > - It allows deferring the "mergeability of the PR if up to date > with target branch" to GitHub. If the contributor want a new build, then > the PR's originating branch must be updated to match the target branch. > > In this case there is little point in retaining the PR merge configuration at all; it would be simpler to just switch to building PR heads only, and perhaps (on a repo-by-repo basis) requiring PRs to be up to date with the base branch before merging except with admin-level override. This is what I have long advocated in INFRA-1633. The key question is what the workflow will be for the handful of people who actually merge PRs to core (`jenkins`), or other repos with very long CI cycles like `acceptance-test-harness`. If there is a large backlog of `ready-to-merge` PRs, then you have some choices to make. Off the top of my head, options include: · The current system, where every merged PR triggers rebuilds of all of the others, and I suppose mergers only merge PRs with currently passing status. · The current system plus ad-hoc manual marking of some PRs (presumably not those which are `ready-to-merge`) to get fewer or no builds. · A simple manual system with `master` protected; mergers will need to process PRs serially, in each case updating the base branch, waiting for CI to finish, then merging. Reasonable for repos with quick CI and/or low PR volume but painful for a few important repos. · The above amended by GH’s automerge feature. Not sure if you can turn on automerge if you are not the author. Still need to manually click the button to merge in the base branch, and still serial, but at least you do not need to sit around waiting for CI to finish. · A serial merge system with some more help from some bot or another. · A batch merge system: optimistically pulls together the base branch plus a whole pool of PRs which are otherwise ready (reviewed, head commit passing), builds the octopus merge, and if it is passes merges them all at once. · YOLO: merge PRs whose head commit passed CI, and if that happens to introduce a failure in `master` due to semantic conflicts between two recent PRs (unusual but can happen), deal with it by fixing up the issue or at worst reverting the last merge and reopening the faulty PR. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1SvZdqY4KEERASeHepOEhOEvdqBCY00u0Nfi%2BvcMhLcA%40mail.gmail.com.
