Allow disabled jobs to still run as PRs
#2704 changed the logic from "PR jobs are completely independent of their parent jobs" to "PR jobs are force-disabled if their parent jobs are disabled".
Given that #2704 was opened in the first place, there are definitely use-cases where the new logic is desirable. However, there are also use-cases where the new logic causes problems:
-
Some jobs are designed to be permanently PR-only: consider a pipeline with both a
mainjob triggered on~commit, and aprjob triggered on~pr. Disabling the parentprjob is an extra safeguard that prevents it from being manually triggered in a non-PR context -
In other cases, the same job can be used for both
~commitand~pr. There are times when it's useful to disable the~commitjob if (e.g.) you don't want a new artifact produced, or a deployment to be run. Consider a repo that runsterraformto manage deployments: the~commitbuilds runterraform apply, and the~prbuilds runterraform plan. If we don't want anapplyto happen, we can disable the job - however, that also prevents the PR job from running, even thoughplanis entirely safe to still run in the PR context.
I put a couple of ideas on #2704 on possible resolutions:
- Make the job state a non-boolean - essentially two independent toggles, one for the existing enabled/disabled and a second for "PRs enabled/disabled"
- Add a job-level (or pipeline-level?) annotation for indicating whether PRs can run when parent jobs are disabled. Maybe a
screwdriver.cd/disabledJobsRunPRs: true|false(ornever|manually|always, or some other set of options) - Instead of always checking the parent job's state, when creating a PR job, inherit the state from the parent job, but then allow it to be independently modified. This would be more steps for users, but it would at least provide an avenue to run builds if needed (by reenabling the specific PR job, and then triggering a build)
The current error message banner wasn't very clear. Giving indication about disabled job would be helpful.