Proposal for afiltering PR labels + ignore PR's target branche update for https://ci.jenkins.io/job/Core

[Damien Duportal]

Hello there,

This is a proposal to make a configuration change for the GitHub organization scanning "Core" on ci.jenkins.io (https://ci.jenkins.io/job/Core).

2 items are targeted:

• Filtering out, in the "Behavior" section, the PRs which has a label "on-hold" or "ci-skip".
  
  • Goal: allow a contributor to open a PR without triggering a build (<joke>build slots are scarce resources ;)</joke>)
    
  • We are currently doing this on the infra.ci.jenkins.io (as per https://github.com/jenkins-infra/charts/pull/721 for instance)
• Enabling the option “Ignore rebuilding merge branches when only the target branch changed” in the section “Build Strategy”
  • Goal: avoid triggering a build for a given PR each time that the target is updated
  • 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.
    

I would like to know (learn?) if we can apply this without disrupting your work and avoid costing too much time, while trying to add a new valuable behavior and sparing some resources.

The risks are related to the fact that applying this setting would impact all of the following projects, members of the scanned organization:

• jenkins-test-harness
• jenkins-test-harness-htmlunit
• sshd-module
• slave-installer-module
• windows-slave-installer-module
• jenkins
• pom
• remoting
• winstone
• acceptance-test-harness
• core-pr-tester

Is there any objection to these changes? Anything that does not make sense?

Cheers,

Damien D.

PS : If I obviously misunderstood something, or did not follow a specific process, please pardon my "newbiness" here and point the mistake promptly so I can change direction and improve

[Oleg Nenashev]

+1 for the first proposal, +0.5 for the second one.

In general we do not need the "always latest target" strategy for core patches (and yes, ATH is massive...). Maybe we should keep it for LTS backporting PRs if the configuration allows that

> If the contributor want a new build, then the PR's originating branch must be updated to match the target branch.

Currently Core Maintainers should be able to retrigger builds on-demand.

It should lead to re-merge with the target branch.

BR, Oleg

[Damien Duportal]

Le 3 févr. 2021 à 15:21, Oleg Nenashev <o.v.ne...@gmail.com> a écrit :

+1 for the first proposal, +0.5 for the second one.

In general we do not need the "always latest target" strategy for core patches (and yes, ATH is massive...). Maybe we should keep it for LTS backporting PRs if the configuration allows that

> If the contributor want a new build, then the PR's originating branch must be updated to match the target branch.

Currently Core Maintainers should be able to retrigger builds on-demand.

It should lead to re-merge with the target branch.

My understanding and experience with the "Build Strategy" option  “Ignore rebuilding merge branches when only the target branch changed” is the following:

1. PR-A opened: An initial build is triggered
2. Then, the target branch is updated (PR-B has been merged): an event is sent to Jenkins, which will rebuild the target branch (of course: new commit), but it won’t re-trigger a build on PR-A
3. The author of PR-A pushes to the branch after a rebase /merge from target’s branch: originating branch’s code is updated so Jenkins triggers a new build

However I’m don’t know if a manual build is triggered, in Jenkins, between steps 2. and 3., if the build will do something.

=> Does it means that we might have different configuration between the multibranch jobs here (compared to a single GH Organization scanning)?

Can the Pipeline of each repo override these 2 options per project?

Damien

-- 
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/FzX-Ph5U-6s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/10c7edf8-acd2-4e4a-86dd-3b7b7dc97534n%40googlegroups.com.

[Jesse Glick]

On Wed, Feb 3, 2021 at 9:14 AM Damien Duportal <damien....@gmail.com> 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.