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/07e6e8cf-4dd9-4061-acc0-e6cfa0131917%40googlegroups.com.
