Workflows, Jobs, Steps, and Actions

In one line

GitHub Actions' own vocabulary maps directly onto Phase 0.2's universal pipeline model — a workflow is the pipeline, jobs are its stages' work, steps are individual commands, and actions are reusable building blocks anyone can publish.

0/4 · 0%

Key ideas

01
A WORKFLOW is one YAML file in .github/workflows/, defining the complete automated process — this maps directly onto Phase 0.2's 'pipeline,' just GitHub's own specific term for it, triggered by whatever on: condition it declares (Phase 1.1).
02
A JOB is a set of steps that run together on the SAME runner — by default, every job in a workflow runs in PARALLEL unless a needs: dependency is declared (Topic 1.4 already showed this), and each job gets its own genuinely fresh, isolated runner environment, separate from every other job.
03
A STEP is one individual action within a job — either a plain shell command (run: mvn test) or a reusable ACTION (uses: actions/checkout@v4) — steps within the SAME job run sequentially, in order, and share the same workspace and filesystem state as the job progresses.
04
An ACTION is a genuinely reusable, packaged piece of automation — actions/checkout (clones your repo), actions/setup-java (installs a specific JDK version), and thousands of others published by GitHub itself, by tool vendors, and by the open-source community on the GitHub Marketplace, each callable with uses: <owner>/<repo>@<version>.
05
Pinning an action's VERSION matters genuinely for both stability and security — @v4 (a major version tag) gets automatic minor updates, while @<full-commit-sha> pins to an EXACT, immutable version, genuinely the safest choice for anything security-sensitive, since a tag can theoretically be moved to point at different code later, while a specific commit SHA cannot.
06
env: sets environment variables at the workflow, job, or step level (Linux's own course, Phase 5.3, already covered why environment variables are the standard way configuration reaches a running process) — and GitHub Actions provides built-in CONTEXT variables (github.sha, github.actor, github.ref) automatically, giving every workflow run access to genuinely useful metadata about the specific event that triggered it, with zero extra configuration.

Code & diagrams

WorkflowAnatomydiagram

The exact same shape as Phase 0.2's universal model, now with GitHub's own specific vocabulary.

Rendering diagram…

workflow-anatomy.ymlmarkdown

Every piece from this topic, in one realistic file.

name: CI

on:
  push:
    branches: [main]

env:
  JAVA_VERSION: "21"     # workflow-level, available to every job

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4        # a published, reusable action

      - name: Set up Java
        uses: actions/setup-java@v4
        with:
          java-version: ${{ env.JAVA_VERSION }}
          distribution: "temurin"

      - name: Show the triggering commit
        run: echo "Building commit ${{ github.sha }} by ${{ github.actor }}"

      - name: Build and test
        run: mvn clean package

Explain it without notes

Why do jobs in the same workflow run in parallel by default, while steps within the same job run sequentially?

What's the practical security difference between pinning an action to @v4 versus a specific commit SHA?

Practice

Create a workflow with two independent jobs (no needs: between them) and confirm in GitHub's Actions UI that they genuinely start and run at the same time, not sequentially.

Find any action in a workflow you've written (or GitHub's own actions/checkout) and look up how to pin it to a specific commit SHA instead of a version tag.

Trade-offs

↔
Using many small, specific, well-tested community actions is genuinely faster to build a working pipeline than writing every step as a raw shell command yourself — but it also means trusting third-party code (even a widely-used action is still code you didn't write) to run inside your CI environment, which is exactly why pinning to a specific commit SHA (rather than a moveable tag) matters more for actions handling anything sensitive, like secrets or deployment credentials.

Done when you can

I can map GitHub Actions' workflow/job/step/action vocabulary onto Phase 0.2's universal pipeline model.
I understand why jobs run in parallel by default while steps within a job run sequentially.
I know the security trade-off between pinning an action to a version tag versus a specific commit SHA.