runner: Command to early-exit the job and set check conclusion

This is useful to not repeat the same if statement many times, you can instead do an early exit

This is really useful and is quite needed!

really github? we can’t abort a workflow? it’s 2022

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…

Any update on when this might be resolved?

Are there any updates on this feature? I was checking the roadmap I was not able to find any related issues

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.

You bumped an issue that was already bumped 2 hours ago. Please read instead of spamming people with emails.

Right now, I have to use if on each subsequent step. This would be a huge improvement in usability and readability.

How does this have 771 likes and is not implemented 👍 ?

bump

Can someone from GitHub at least tell us how likely we are to get this feature request implemented?

It’s such an obvious win as far as many of us can tell but maybe there are difficulties we are unaware of.

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 😦

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"

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.

How about step instead of command?

steps:
  - exit: success()
    if: failure()

steps:
  - exit: failure()
    if: steps.step1.outputs.count > 0

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 really hope they add this soon 🤞

Also interested in this feature

@ndiaz-addepar, I think you answered your own question. 😉

This has been opened for three years Is there going to be any progress here ?

Any updates on this? 🥹 this is a must have

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.

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.

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 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!..

Is there any update?

This needs to be check and implemented, we need a way to skip the rest of the steps if we need to.

Has anyone found a work-around for this? Thanks

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

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.

Any update on this?

This could help us tremendously to cleanup our workflows and make them more readable 😃