Memory hook: Jobs form the graph; steps share a job; contexts supply data.
Must remember
Jobs run independently unless needs declares dependencies. Steps within a job run in order on that job's runner. Separate jobs do not share a filesystem by default. if controls eligibility, and status functions influence behavior after failure/cancellation; use cleanup conditions carefully so they do not create hangs or unwanted deployment.
A matrix expands combinations such as OS and runtime version. include adds/adjusts combinations; exclude removes combinations. fail-fast controls cancellation of related matrix jobs after failures, while max-parallel limits concurrent variants. Count the expanded jobs before estimating runtime or cost.
Expressions use contexts such as github, inputs, matrix, needs, steps, runner, vars and secrets. Workflow evaluation and runner-shell expansion occur at different times. Environment variables available in a shell are not automatically available in every workflow expression field. Preserve types deliberately when working with boolean inputs and JSON outputs.
Service containers provide dependencies such as a test database, with ports and health checks. A job running inside a container reaches services differently from a job directly on the runner; use the appropriate hostname/port mapping. Container support depends on runner OS/platform.
YAML anchors (&) name reusable nodes; aliases (*) reference them. A YAML merge key (<<) conventionally combines mappings, with explicit keys overriding merged values. The exam outline names merge mappings, but verify runtime support rather than assuming all YAML processors implement them. Editor schema/Actions extensions catch many structural mistakes; they cannot prove the workflow is secure or correct.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Deploy only after two test jobs pass | needs dependencies and suitable conditions. |
| Test several OS/runtime pairs | A bounded matrix. |
| Database required only for integration tests | A service container with readiness checks. |
Traps
- GITHUB_ENV does not share files or variables with a different job.
- A valid YAML document is not necessarily a valid Actions workflow.
Active recall
1. Job versus step?
An independently scheduled execution unit versus an ordered operation within a job.
2. fail-fast versus max-parallel?
Cancel related matrix work after failure versus limit concurrency.
3. Why distinguish expressions from shell variables?
They are evaluated by different components at different times.
4. Why use a service health check?
The container may start before the service is ready to accept requests.
5. What should be checked before using YAML merge keys?
Actual Actions parser support, not just general YAML semantics.
Sources
- actions · reference · workflows-and-actions · workflow-syntax
- actions · reference · workflows-and-actions · contexts
- actions · how-tos · write-workflows · choose-what-workflows-do · run-job-variations
- actions · concepts · use-cases · about-service-containers
- actions · reference · workflows-and-actions · reusing-workflow-configurations