Intermediate 15 terms

GitHub Actions

Core GitHub Actions concepts: workflows, triggers, jobs, steps, runners, caching, secrets, and OIDC.

  • workflow /ˈwɜːkfləʊ/

    YAML file in .github/workflows/ defining one or more automated processes; triggered by events and composed of jobs.

    "We have three workflows: ci.yml runs tests on every push, deploy.yml deploys on merge to main, and nightly.yml runs the full test suite at midnight."
  • trigger /ˈtrɪɡər/

    The on: key in a workflow specifying which events start it: push, pull_request, schedule, release, or workflow_dispatch for manual runs.

    "We added workflow_dispatch to the deploy workflow so we can manually kick off a deployment from the GitHub UI without pushing a commit."
  • job /dʒɒb/

    A set of steps that execute on the same runner; jobs run in parallel by default unless a needs: dependency is declared.

    "The test job and the lint job run in parallel to save time; the deploy job has needs: [test, lint] so it only runs if both pass."
  • step /step/

    An individual task within a job; either runs a shell command with run: or invokes a reusable action with uses:.

    "The build step runs npm run build and the upload step uses actions/upload-artifact to store the dist folder for later jobs."
  • action /ˈækʃən/

    Reusable unit of code published to the GitHub Marketplace or stored locally; invoked with uses: in a workflow step.

    "We use actions/checkout to clone the repo, actions/setup-node to install Node.js, and a custom local action for our deployment logic."
  • runner /ˈrʌnər/

    The virtual machine or physical server that executes a job; GitHub-hosted runners offer ubuntu-latest, windows-latest, and macos-latest.

    "Our integration tests run on a self-hosted runner inside our VPC so they can reach internal services that GitHub-hosted runners cannot."
  • artifact /ˈɑːtɪfækt/

    File or directory uploaded during a workflow using actions/upload-artifact; downloadable from the Actions UI and passable between jobs.

    "The build job uploads the compiled binary as an artifact and the deploy job downloads it — they run on different runners but share the output."
  • secret /ˈsiːkrɪt/

    Encrypted value stored in repository or organisation settings; accessed in workflows as ${{ secrets.NAME }} and masked in logs.

    "The deploy workflow reads ${{ secrets.SSH_PRIVATE_KEY }} to authenticate with the production server — the value never appears in the workflow logs."
  • environment /ɪnˈvaɪərənmənt/

    Named deployment target (e.g. staging, production) with optional required reviewers and branch protection rules.

    "The production environment requires approval from two senior engineers — a workflow deploying to it pauses until both click Approve in the GitHub UI."
  • matrix strategy /ˈmeɪtrɪks ˈstrætədʒi/

    Runs the same job with multiple parameter combinations; commonly used to test against several OS or language versions simultaneously.

    "Our matrix tests against Node.js 18, 20, and 22 on Ubuntu and Windows — six jobs run in parallel from a single job definition."
  • concurrency /kənˈkʌrənsi/

    Workflow setting that controls whether a new run cancels in-progress runs for the same group key; prevents stale deploys from overwriting newer ones.

    "Setting concurrency to the branch name means pushing twice in quick succession cancels the first deploy workflow before the newer one starts."
  • if condition /ɪf kənˈdɪʃən/

    Expression on a step or job that controls whether it runs; evaluated against GitHub context variables like github.ref and job.status.

    "The notify step has if: failure() so it only sends a Slack alert when the job fails — it is skipped on successful runs."
  • cache action /kæʃ ˈækʃən/

    actions/cache; stores and restores files between workflow runs keyed by a hash; commonly used for node_modules and build outputs.

    "Caching node_modules with a key based on package-lock.json hash reduced our CI time from 4 minutes to 90 seconds."
  • GITHUB_TOKEN /ɡɪtˈhʌb ˈtəʊkən/

    Automatically provisioned token with repository permissions; scoped to the current workflow run. Used for API calls, publishing releases, and commenting on PRs.

    "The release job uses GITHUB_TOKEN to create a GitHub Release and upload the compiled binaries — no personal access token required."
  • OIDC /əʊ aɪ diː siː/

    OpenID Connect; allows workflow jobs to exchange short-lived tokens with cloud providers like AWS and GCP without storing long-lived credentials as secrets.

    "With OIDC, our deploy job assumes an AWS IAM role directly from GitHub Actions — no AWS_ACCESS_KEY_ID secret to rotate or accidentally expose."

Ready to practice?

Test your knowledge of these terms in the interactive exercise.

Start exercise →