Suppressing builds on master branch
#1993
Conversation
|
https://github.com/jenkinsci/bom/pull/1993/checks?check_run_id=12935716671 |
Would not work, since a release tag is created only after a successful build. Not bothering to wait for full build, since the rest of the build should be unaffected (except for |
I was thinking of a tag pushed manually. Probably a flawed reasoning, and less practical than your solution anyway. |
Oh I see. Could probably be made to work, though it would require some changes to multibranch config and is a bit further afield from how JEP-229 normally works. |
| @@ -1,5 +1,9 @@ | |||
| properties([disableConcurrentBuilds(abortPrevious: true), buildDiscarder(logRotator(numToKeepStr: '7'))]) | |||
|
|
|||
| if (BRANCH_NAME == 'master' && currentBuild.buildCauses*._class == ['jenkins.branch.BranchEventCause']) { | |||
| error 'No longer running builds on response to master branch pushes. If you wish to cut a release, use “Re-run checks” from this failing check in https://github.com/jenkinsci/bom/commits/master' | |||
There was a problem hiding this comment.
why do we need to error? can't we just skip the build with a return?
the build already passed on the PR before merging.
There was a problem hiding this comment.
If we do not fail the build then there is no failing check, and GH does not offer to rerun a passing check.
Should basically be cosmetic, but there may be some fancier way to create a dedicated failing check without actually failing the build. (Could then set the status to NOT_BUILT for example.) I am not sure if github-checks allows that using generic steps. Might work to use the publishChecks step.
There was a problem hiding this comment.
do we need a failing check? you can create a pull request to test a build and it won't be on master if it hasn't passed on a pull request.
it's not ideal to open the repository and just see red.
There was a problem hiding this comment.
you can create a pull request to test a build and it won't be on master if it hasn't passed on a pull request.
Sorry, I did not follow that sentence.
it's not ideal to open the repository and just see red.
Of course, but I do not see an alternative. Even if the Jenkins build is marked successful, the alternate failing check trick I proposed in #1993 (comment) would still result in the commit being shown as failed.
To recap, the idea of this PR is to make master builds do nothing if triggered by SCM; but offer a mechanism by which someone with write permission to this repository yet no special permissions on ci.jenkins.io can somehow trigger a real build of master on demand, which if successful will then proceed to trigger a CD release as usual (depending on labels). The only way I could think of to make that happen is to make the last master commit be marked with some failing check, so that Re-run is offered, at which point we can inspect the build causes and decide to proceed. Letting the master build be marked successful means that only people with elevated permissions on the CI server (of whom I at least am not one) would be able to trigger bom releases, contrary to the basic goal of JEP-229. If you have a better idea, please do tell.
Note one effect of this change is that the next pseudorelease will not be populated by Release Drafter until the release is actually cut, since the stock CD workflow checks statuses first and only then runs R.D. If desired, we could clone & modify this workflow to run R.D. earlier, for example after every master build completes, whether successful or not.
There was a problem hiding this comment.
what I mean though is why do we need to run a successful build of bom on master? i.e. with branch protection configured here it assures that it passed on the PR build and there's nothing different in this repo between PR and master can't we just auto release on master if labels match?
There was a problem hiding this comment.
Oh I see. That would be possible. There are two considerations though:
- This PR ensures that the remaining
masterbuilds test all LTS branches, so it is actually safer than the prior setup. To replicate that safety with your proposed setup, the onus would be on whoever merged a PR with an “interesting” label to remember to run a build with thefull-testlabel first. - Since Jenkins PR-merge strategy is long since disabled, and we are not using a GH merge queue, a passing PR-head build does not guarantee that all is well after the merge. It would then become possible for a
bomrelease to be cut from a revision which is actually broken. We would notice pretty soon (when new DB PRs start consistently failing with the same error with no apparent relation to the diff) and issue a revert or correction, but it still makes me nervous. (For the same reason, the JEP-229 workflow generally checksmasterstatus, even though we expect it “should” be passing.)
I have no strong opinion, so if you want to experiment with another policy, go ahead.
Trying to minimize load on ci.jenkins.io by only building PRs by default; if and when you want to run a release, use Re-run in GitHub to do a
masterbuild that could trigger CD. jenkins-infra/helpdesk#3521 (comment)