+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 On Wednesday, February 3, 2021 at 3:14:05 PM UTC+1 [email protected] wrote: > > 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 > > > > > > -- 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/10c7edf8-acd2-4e4a-86dd-3b7b7dc97534n%40googlegroups.com.
