This gets my vote - exactly the sequence that I've wished existed for some time now.
On Thu, Apr 23, 2020 at 8:55 PM Liam Newman <[email protected]> wrote: > > 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 > <https://groups.google.com/d/msgid/jenkinsci-dev/9c8b5674-4d91-4b31-927c-2981ffac0112%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAEWqh9GZnZmCg-0RekFQ_0PuJWHbho8GrQ3sMiRGoNb_MMtu1w%40mail.gmail.com.
