runner
runner copied to clipboard
actions
Command to early-exit the job and set check conclusion
Describe the enhancement
Currently to skip the rest of steps during a job, an if condition has to be added to all of steps or steps have to be moved to another job.
It'd be nice to have a command to early-exit (premature, prematurely, graceful, gracefully) (end, finish, terminate, termination, stop, halt, skip, cancel, discontinue, fail) the job during a step without failing the job:
::exit::
It'd be also nice to set the conclusion of early-exited job:
::exit::failure
(equivalent to exit 1)
or
::exit::neutral
(equivalent to exit 78 in Actions v1)
and other check conclusions.
This would help save build time for both GitHub and customers.
Additional information
Related StackOverflow and GitHub Community posts:
- How to fail a job in Github Actions?
- How to force to exit in Github Actions step
- How to write a GitHub Action with a neutral Check Run status
- How to perform an early clean exit of a job ?
- Early successful termination of job
- Github Action Skip Steps/Fall Through Syntax
Related issues:
- https://github.com/actions/toolkit/issues/146
- https://github.com/veggiemonk/skip-commit
Other CIs:
- CircleCI:
circleci-agent step halt - Travis CI:
travis_terminate - AppVeyor:
appveyor exit(Linux) - Jenkins:
currentBuild.result - GitLab CI:
exit 0
This is useful to not repeat the same if statement many times, you can instead do an early exit
This would be a great addition. Right now I have a pre-condition that I can only check in a bash-script, and I'm exiting with exit 1 for a purpose. However, in my PR it shows up as a failure :(
I can't believe GHA does not support this. I guess you need to just implement and entire job as one big step run by your own driver script and then you can put whatever logic you want in that script to terminate early and with a zero exist (and a nice informational message). Is that the only current workaround for this?
GHA seems to be a new unique declarative language with somewhat limited functionality.
How about step instead of command?
steps:
- exit: success()
if: failure()
steps:
- exit: failure()
if: steps.step1.outputs.count > 0
A couple of untested ideas as partial workarounds:
- A step could cancel the whole workflow using the REST API - https://docs.github.com/en/rest/reference/actions#cancel-a-workflow-run
- One workflow could contain the initial check, with the remaining steps in a separate workflow which is conditionally triggered by the first workflow.
This would be extremely useful especially with the addition of:
- https://github.com/actions/runner/pull/1302
If this functionality was available one could re-create the re-run workflow from failed feature that's popular within CircleCI
- One workflow could contain the initial check, with the remaining steps in a separate workflow which is conditionally triggered by the first workflow. I don’t see how this could work. A workflow triggered by another workflow run will run whether the other workflow succeeded or failed; you can’t filter based on its conclusion.
Another workaround is to define all of the conditional steps in a composite action, and then make the invoking of the composite action conditional. This has limitations, though, because composite actions do not support all of the syntax in workflow files.
I have a use case that's not really solved with conditional steps.
In the case I'm trying to solve for, we want to set the check condition to the neutral status.
The use case is pretty simple. We would like to warn the users that their commit messages may be missing information. However, some of that information is optional and shouldn't block a PR from being merged if it's intentionally missing. A skipped or success status gives the wrong impression. The neutral status seems to be the next best thing in the absence of a warning status.
Are there any updates on this feature? I was checking the roadmap I was not able to find any related issues
No way. Two years without such a simple solution? We just need a job to finish the workflow with success or not.
Why is this so hard to implement?
It was already implemented in V1 version of GitHub Actions.
By some reason, they broke it, therefore it’s not possible right now anymore.
Was there some reasoning behind that? Was that just a mistake?
Nobody knows. GitHub seems quiet about that. Not because of «it’s hard».
IMO highly likely just another bureaucracy moment.
How can we pressure to higher the priority here?
This issue has more than 300 likes.
Spamming messages here definitely won't help
There's «Contact Github» link in the footer, maybe it's more appropriate way to send feedback, if nobody created it there yet:
https://support.github.com/features/feedback
This needs to be check and implemented, we need a way to skip the rest of the steps if we need to.
You bumped an issue that was already bumped 2 hours ago. Please read instead of spamming people with emails.
This would be a great addition. Right now I have a pre-condition that I can only check in a bash-script, and I'm exiting with
exit 1for a purpose. However, in my PR it shows up as a failure :(
Instead of using the exit 1 / exit 0 pattern, You can make the first step always return 0 code, and setting the correct string outputs, https://docs.github.com/en/actions/using-jobs/defining-outputs-for-jobs
jobs:
check:
outputs:
status: ${{ steps.early.outputs.status }}
steps:
- name: Checkout
uses: actions/checkout@v3
- id: early
name: Branch check
run: |
status="skip"
if $condition
then
status="deploy"
fi
echo "status=$status" >> $GITHUB_OUTPUT
deploy:
name: Deploy
needs: check
if: needs.check.outputs.status == 'deploy'
steps:
- name: Checkout
uses: actions/checkout@v3
- name: Do the heavy deploy
run: |
echo "This runs only when condition=$condition is met, otherwise it will be skipped"
This is a little old and unanswered issue, but I believe it deserves an explanation.
This happens because the default bash shell for linux/macos runs with -o pipefail. You can override it, and it is documented in Workflow syntax for GitHub Actions: Exit codes and error action preference.
In short, just use in the step, besides the run section, a shell either
shell: bash {0}
Or maybe similar to the default, without pipefail:
shell: /bin/bash --noprofile --norc -e {0}
You can see what current shell command your workflow is using in the logs, like this:
Another way to avoid this is just handle the commands that potentially can return error, like
my_dangerous_command || true
to completely ignore its return status or
success=true
my_dangerous_command || success=false
if ! ${success}; then
echo "The command failed."
else
echo "Dangerous command is good. Let's carry on."
fi
This should make script handling a bit easier, but beware of your steps that rely on early quitting to determine whether they're good or not!..
This may be helpful for some wanting to continue execution within a Bash script, although pipefail is considered a best practice in Bash development, GitHub Actions doesn't set -eo pipefail unless you explicitly set shell: bash, and most people are usually better off with Python scripts in my experience. Regardless of my personal opinion, this doesn't address the original issue, which is about preventing execution of subsequent workflow steps in a successful job.
really github? we can't abort a workflow? it's 2022
2023 is not looking much better either. This is the most upvoted open issue in the repository, open for almost 3 years and I haven't noticed any indication that there would even be a plan to work on this. Happy to be proven wrong...
Yeah this is basic functionality that is very much due for implementation. Please fix. I don't understand how it can take years and years to get something as basic as this implemented, especially considering the amount of upvotes.
This could help us tremendously to cleanup our workflows and make them more readable :)
