Conditional Execution and Job Dependencies

Not every step should run every time. You might want a deploy step to run only on the main branch, or a notification step to run only when something failed.

GitHub Actions lets you attach an if condition to any step or job to control whether it executes.

Add an if: key to a step. The step only runs when the expression evaluates to true.

Expressions inside if do not need the ${{ }} wrapper, though it is allowed.

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.

Test your understanding of conditional execution.

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.