- Control step and job execution with
ifconditions - Allow workflows to continue after failures using
continue-on-error - Inspect outcomes with status-check functions (
success(),failure(), etc.)
Sample Workflow Overview
- testing: Runs tests on both Windows and Ubuntu, setting an
apikey. - reports: Uploads test results to AWS S3 and deliberately fails.
- deploy: Depends on the
reportsjob.
export (and PowerShell commands won’t execute on Linux), the testing job fails for one matrix entry, blocking all downstream jobs.
Storing secrets directly in your workflow can expose them in logs. Use GitHub Secrets instead.
Core Expressions in GitHub Actions
Expressions let you dynamically control when a step or job runs. There are three main categories:- Conditional execution with
if - Error handling with
continue-on-error - Status inspection functions (
success(),failure(), etc.)
1. Conditional Execution with if
Use if to evaluate expressions based on contexts, comparisons, and built-in functions:
runner.os,github.ref, and other contexts provide metadata.- Combine expressions using
&&,||,==,!=, and functions.
2. Allowing Failures with continue-on-error
By default, a failed step stops its job. Enable continue-on-error to proceed even if a step or job fails:
Use
continue-on-error carefully—it can mask genuine failures if overused.3. Status Check Functions
Inspect the results of prior steps or jobs with these functions:| Function | Description |
|---|---|
| success() | Returns true if all prior steps/jobs succeeded |
| failure() | Returns true if any prior step/job failed |
| cancelled() | Returns true if the workflow or job was cancelled |
| always() | Returns true regardless of prior outcomes |
Fixing the Sample Workflow
Let’s apply these expressions to our initial example so each test runs only on its matching OS, and downstream jobs aren’t blocked by failures.- The two
ifchecks skip non-matching OS steps, ensuringtestingalways passes. continue-on-error: trueonreportsletsdeployrun even if the upload step fails.