Update failure with additional conditions

[alexbrazier]

Why:

Closes #18269

What's being changed:

The docs in the "Evaluate Status Explicitly" section suggest equivalents of failure() but neither work. I've updated the docs to remove them and also added a practical example of only running a failure jobs when a specific job fails.

Example action with previous broken code and updated working code

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: fail demo
        id: demo
        run: exit 1

      - name: action_status - does not run
        if: ${{ github.action_status == 'failure' }}
        run: echo ${{ steps.demo.conclusion }}

      - name: status - does not run
        if: ${{ job.status == 'failure' }}
        run: echo "test"

      - name: failure - runs
        if: ${{ failure() }}
        run: echo "test"

      - name: failure with condition - runs
        if: ${{ failure() && steps.demo.conclusion == 'failure' }}
        run: echo "test"

      - name: condition without failure - does not run
        if: ${{ steps.demo.conclusion == 'failure' }}
        run: echo "test"

From the above testing failure() is always required if you want the job to run on a failure regardless of other expressions that might match.

Check off the following:

• I have reviewed my changes in staging (look for "Automatically generated comment" and click Modified to view your latest changes).
• For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

• This pull request impacts the contribution experience
  • I have added the 'writer impact' label
  • I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

[welcome]

Thanks for opening this pull request! A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines.

[github-actions]

Automatically generated comment ℹ️

This comment is automatically generated and will be overwritten every time changes are committed to this branch.

The table contains an overview of files in the content directory that have been changed in this pull request. It's provided to make it easy to review your changes on the staging site. Please note that changes to the data directory will not show up in this table.

---

Content directory changes

You may find it useful to copy this table into the pull request summary. There you can edit it to share links to important articles or changes and to give a high-level overview of how the changes in your pull request support the overall goals of the pull request.

Source	Preview	Production	What Changed
actions/learn-github-actions/expressions.md	fpt ghec ghes@ 3.5 3.4 3.3 3.2 3.1 ghae	fpt ghec ghes@ 3.5 3.4 3.3 3.2 3.1 ghae

[lucascosti]

👋 @alexbrazier Thanks for opening this PR!

github.action_status in your example is not used correctly, as that context only applies to workflows that use a composite action (which your example workflow doesn't). So that value wouldn't be populated, and the behavior you're seeing is expected

However, I have reproduced what you're seeing for job.status and steps.demo.conclusion in a workflow. I have echoed the values of those contexts in a step , and they do contain the string failure, so I'm not sure why the comparison operator is not working.

I'll see if I can get an engineer or product person to have a look at this, as it might be a bug.

[github-actions]

Thanks for opening a pull request! We've triaged this issue for technical review by a subject matter expert 👀

[lucascosti]

👋 @alexbrazier, I've confirmed that the behavior is because there is an implicit success() condition in if conditionals that don't include a status check function. This is mentioned at the start of the section, and you can see this behavior in a workflow run with debug logging here.

So, your fix of including failure() in the condition works, or alternatively including always(). I'll do a small edit to your PR and merge it 🚀

[lucascosti]

👍

[github-actions]

Thanks very much for contributing! Your pull request has been merged 🎉 You should see your changes appear on the site in approximately 24 hours. If you're looking for your next contribution, check out our help wanted issues ⚡

[alexbrazier]

Hi @lucascosti, that makes sense - I had assumed there was either a bug somewhere or an issue with the docs. Thanks for looking into it and merging the changes!