Jobs and Steps

Jobs and Steps

A job is the primary scheduling and isolation boundary in GitHub Actions. All steps in one job share its runner filesystem and execute in order. Separate jobs can run concurrently unless needs creates a dependency graph.

Core ideas

• A run step executes a shell command; a uses step invokes an action.
• needs orders jobs and exposes upstream results and declared outputs.
• Step outputs are written to $GITHUB_OUTPUT; job outputs promote selected values for downstream jobs.
• if conditions control jobs or steps. Use always(), failure(), or cancelled() deliberately for cleanup and reporting.

How it works

Use jobs to separate trust boundaries, platforms, or independently retryable phases. Within a job, keep steps focused and named. Files do not automatically cross job boundaries because hosted jobs receive different runners; upload an artifact or rebuild from the same source when another job needs output.

Configuration example

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      version: ${{ steps.meta.outputs.version }}
    steps:
      - id: meta
        run: echo "version=1.4.${GITHUB_RUN_NUMBER}" >> "$GITHUB_OUTPUT"
      - run: ./scripts/build.sh

  publish:
    needs: build
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - run: echo "Publishing ${{ needs.build.outputs.version }}"

Read the example from top to bottom: the trigger creates a run, the job requests a runner, and each step receives only the context configured for it. Adapt names, versions, permissions, and commands to the repository rather than copying production credentials or policies blindly.

Production guidance

• Use set -euo pipefail or an equivalent strict mode in non-trivial shell scripts.
• Move complex scripts into versioned repository files so they can be tested locally.
• Set job timeouts and make cleanup steps conditional with if: always() when cleanup must run after failure.

The chapter quiz follows this lesson and checks both the vocabulary and the operational decisions behind the configuration.