Re: Periodic rebuilding of core PRs on ci.jenkins.io through branch indexing

By the way, we could try running a GitHub merge queue for the `jenkins@master` branch. I experimented with it recently. It does prevent the possibility of an undetected logical conflict, without requiring a person to be standing by manually updating each PR and waiting for CI to be green before

Re: Periodic rebuilding of core PRs on ci.jenkins.io through branch indexing

I've switched it to pr-head for a trial run. (Core and Tools folders only) Jesse has been advocating it for over 4 years now. Let's give it a go. Easy to revert back if we find pr-merge was better On Wednesday, 6 July 2022 at 18:44:38 UTC+1 Jesse Glick wrote: > On Sun, Jul 3, 2022 at 5:13 AM

Re: Periodic rebuilding of core PRs on ci.jenkins.io through branch indexing

On Sun, Jul 3, 2022 at 5:13 AM Alexander Brandes wrote: > Maybe I'm missing something, but I can see downsides only for this > [PR-merge] strategy > The upside is that the commit status will reflect whether the PR would allow trunk to continue passing if it were merged *now*. With the simpler

Periodic rebuilding of core PRs on ci.jenkins.io through branch indexing

Hey everyone, if I understood the branch strategy correctly, core PRs are periodically rebuilt against the revision of their target branch, if it moves (e.g. after a PR merge). If you take a look at #6745 , you can see that the 1st