early (successful) pipeline exit
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
workaround
Release notes
Originally, jobs flowed one to the next. A non-zero exit status in one stopped the pipeline.
Later, it became possible to ignore a non-zero exit status and continue the pipeline treating the non-zero exit status job as a "warning".
This can be viewed as two distinct bits. One bit determines whether the non-zero exit status is displayed as an error or a warning. The second bit determines whether the pipeline continues.
Logically, we're missing one permutation and it happens to be the permutation that I want.
I want to be able to write a job that exits "successfully" but stops any further jobs in the pipeline from executing. Right now I have to break this into two separate passes through the pipeline with the first making the decision about whether or not to curl a call to the second. This is silly and complicated for what should be a first class feature of the language.
Problem to solve
How does a DevOps engineer write a job that exits the pipeline without raising a failure, sending email, alerting a wider audience, etc?
Intended users
This feature would be exclusively used by DevOps engineers writing pipelines.
User experience goal
There are two users here. The first is the DevOps engineer writing pipelines, which is the primary motivation for the feature.
But a tangential second user is anyone looking at the pipelines UI pages. Since downstream jobs would not be run, they would need to be displayed visually in a way that made it obvious that they were not run. Conveniently, we already have such a visual feature. It simply looks like failure. The proposal is that the pipeline with early (successful) exit be displayed as a warning whose downstream jobs are displayed exactly as downstream jobs are currently displayed following a non-zero exit status job.
Proposal
Allow an early exit. In order to allow for exit conditions including:
- zero exit status (success) and continue (default)
- non-zero exit and stop (failure)
- non-zero exit status and continue (allow_failure aka warning)
- zero exit status (success), and halt (early exit)
Keyword option(s)
critical-job:
script: exit 1
on_status:
fail: fail_pipeline
success: pass_pipeline
cancel:
skip_stage: # Far far far future iterations?
- secondary_tests
skip_job:
- some_jobThe obvious answer would be to add a new keyword akin to allow_failure, perhaps, early_exit. However, the allow_failure paradigm allows for only two possible termination conditions from any single job when we actually have four. All four should be possible from a single job.
Elsewhere I've seen requests for the ability to declare that, eg, exit status 2 be treated as a warning not a failure. That is currently tricky as the current process runs most scripts in such a way that their specific exit status beyond zero/non-zero is lost. I'm not sure how to reconcile these competing requirements although it is clear to me that anything else like an auxiliary script or a special api call to do the job would be unnecessarily complex and fragile. And this leaves me wondering why, in the face of decades of best practice to the contrary, it was decided to discard the specific exit statuses to begin with. Without that understanding I can't offer a particular solution.
Further details
Permissions and Security
Nothing new here.