After

When you specify dependencies using the use keyword, the task inherits the file system contents and environment variables of its dependencies.

If you want to run tasks after other tasks without inheriting the output of the dependencies, you should use the after keyword instead.

A few common scenarios include:

Continuous Deployment workflows, where tasks have side effects of modifying external resources and need to run in a specific order
ETL workflows where state is stored externally and tasks need to run in a specific order
Optimizing build minutes, where you may want to make sure some tasks succeed before running others

Example

tasks:
  - key: one
    run: echo this is task one

  - key: two
    run: echo this is task two

  - key: three
    after: [one, two]
    run: echo task three waits for one and two to finish before running

Running Tasks After Other Tasks Fail

By default, using after means that the task will only run if every task listed in after succeeds. However, you may want to run some tasks after others fail. To do this, you can configure after using an expression instead of an array.

tasks:
  - key: one
    run: exit 1

  - key: if-one-fails
    after: ${{ one.failed }}
    run: echo task one failed!

You can use && and || operators to list multiple tasks within the expression. For more details, see the documentation on expressions.

All tasks are cancelled when the entire run is cancelled. In the previous example, if-one-fails could be cancelled and not run, even if ${{ one.failed }} is true.

If you want to run a task after failure to clean up an external resource, you may want to consider running a periodic task via a cron trigger to look for any resources which were missed.

Status Attributes

To control the after conditions, the following attributes are available on tasks within expressions.

Result status attributes

attribute	description
`succeeded`	The task was successful. It may have executed or been a cache hit.
`failed`	The task failed. It may have executed or failed for another reason such as being cancelled.

Note that skipped tasks, which you can check via .skipped, will return false for both succeeded and failed.

Execution status attributes

attribute	description
`finished`	The task finished running. Notably, `.finished` is false for tasks that are `.aborted` or `.skipped`.
`aborted`	The task was aborted either before or after it started running.
`cancelled`	The task was `aborted` due to being cancelled. Most of the time, you'll want to check `.aborted` instead of `.cancelled`.
`skipped`	The task was skipped. These tasks will return `false` for both `.succeeded` and `.failed`.
`cache-hit`	The task was a cache hit.
`timed-out`	The task was `aborted` due to timing out.

After success or failure

If you want to run a task after another task, regardless of whether that task succeeds or fails, then you currently must check for both states:

${{ (example-task.succeeded || example-task.failed) }}

Failed after running

If you want to run a task after another task fails, but only if that task actually executed (e.g. it finished running and then exited with a non-zero exit status), then you can check:

${{ (example-task.failed && example-task.finished) }}