Conditional Execution and Job Dependencies

Conditions read from context objects that describe the run:

• github — event, ref, actor, sha
• env — environment variables
• job and steps — status of prior work
• runner — OS and architecture

For example, github.event_name tells you whether a push or pull_request triggered the run.

By default, a step is skipped if a previous step failed. To override this, use the status functions:

• success() — true if no prior step failed (the default)
• failure() — true if any prior step failed
• always() — runs no matter what
• cancelled() — true if the run was cancelled

A common pattern is a cleanup step that must run even if earlier steps failed. Use if: always().

This guarantees temporary resources, containers, or test reports are handled regardless of the outcome.

The needs keyword makes one job wait for others. Without it, jobs run in parallel.

A job listed in needs must finish successfully before the dependent job starts.

A job can depend on several jobs by passing a list to needs. It waits for all of them.

This is how you build fan-in patterns, where a final job runs only after parallel jobs all succeed.

The if key works on jobs too, not just steps. A job-level condition decides whether the entire job runs.

Here the deploy job runs only for pushes to main, while still depending on tests.

Jobs can pass data downstream via outputs. A dependent job reads them through the needs context.

This lets a condition depend on a value computed earlier, such as whether a version changed.

You can combine expressions with && (and), || (or), and ! (not).

This example runs only on a successful push to main that is not a fork.

Careful: a job with needs is skipped if a dependency fails. To run a final reporting job regardless, combine needs with if: always().

Inside it you can inspect needs.<job>.result to decide what to report.

You learned to control workflow flow with conditions and dependencies.

• if gates steps and jobs on expressions
• Status functions like failure() and always() override skip-on-failure
• needs creates ordering and fan-in patterns
• Job outputs feed values into later conditions

These primitives let you build precise, efficient pipelines.