Adam, I think the feature/behavior you're suggesting is definitely worth implementing. It would let people safely create new projects without dealing with build storms.
So to reiterate - the behavior we're looking for is: 1. Project is created 2. Branches are indexed, but not built 3. Polling (or hooks) now enabled 4. Scheduled indexing now auto-builds new branches if selected. Hooks will trigger builds You mentioned SkipInitialBuildOnFirstBranchIndexing <https://github.com/jenkinsci/basic-branch-build-strategies-plugin/blob/master/src/main/java/jenkins/branch/buildstrategies/basic/SkipInitialBuildOnFirstBranchIndexing.java> . I think something like that is way to go here. Only instead of disabling the "first indexing of each branch", it would be "Skip Build on First Job Indexing". I know there are several possible ways ways to detect the state "this is the first time a project has been indexed", but I'm not sufficiently knowledgable to be able to point you to the exact right spot. Sorry. But I firmly believe this should be doable without changing the SCM or Branch API. We just need to do some digging to find it. Sound good? -L. On Sunday, April 19, 2020 at 7:44:47 AM UTC-7, Adam Gabryś wrote: > > There are two strategies for building PRs: > 1) test PR before the merge operation - the same as building the source > branch > 2) test PR after the (virtual) merge operation - presents the state after > merging > > We use a second strategy, because the source branch could work standalone, > but break everything with the latest changes. > > It means that if we force developers to create a draft PR to just execute > a build, they will have to: > * create a new branch from the branch which is interesting for them > * create a PR from the new branch to the existing branch > I don't believe any developer would like to use such flow. > > > correct but it will build interesting branches not dangling ones. > > I'm confused about these "interesting" branches and filtering by regex. In > my company people use Git-Flow > <https://nvie.com/posts/a-successful-git-branching-model/>. Branches are > created to work on new features or bug fixes. I would classify all code > changes as interesting to execute on the CI. > -- 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/9c8b5674-4d91-4b31-927c-2981ffac0112%40googlegroups.com.
