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:
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:
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 [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/60463e3b-f7d1-4a83-a4d5-7089f3145d4an%40googlegroups.com. |
+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 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 [hidden email] wrote:
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 [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/10c7edf8-acd2-4e4a-86dd-3b7b7dc97534n%40googlegroups.com. |
My understanding and experience with the "Build Strategy" option “Ignore rebuilding merge branches when only the target branch changed” is the following:
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?
-- 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 [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/A166B1AF-D33F-4D9A-A46F-CC139F5AAD76%40gmail.com. |
In reply to this post by Damien Duportal-2
On Wed, Feb 3, 2021 at 9:14 AM Damien Duportal <[hidden email]> wrote:
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 [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1SvZdqY4KEERASeHepOEhOEvdqBCY00u0Nfi%2BvcMhLcA%40mail.gmail.com. |
Free forum by Nabble | Edit this page |