CI/CD
Advanced 17 min read CI/CD

GitHub Actions

GitHub Actions automates CI/CD natively in GitHub. Master workflows, jobs and steps, hosted runners, expression evaluation, matrix builds, environment protection rules and reusable workflows to build production-grade pipelines.

workflowjobsteprunnerexpressionmatrixenvironmentreusable workflowactions/checkoutGITHUB_TOKEN
Prerequisites: Designing Pipelines Git Remotes & Collaboration
Introduction

What is this?

GitHub Actions is GitHub's CI/CD platform. Workflows are YAML files in .github/workflows triggered by events such as push or pull_request. Jobs run on hosted or self-hosted runners and are composed of steps that run shell commands or community actions. Expressions, matrix builds, environment protection rules and reusable workflows scale it from simple tests to full deployment automation.

Motivation

Why do you need it?

  • CI/CD lives beside the code, so checks and deployments are automatic for every push and PR.
  • A huge marketplace of versioned actions composes into pipelines without writing boilerplate.
  • Matrix builds verify one job across OSes, languages and versions in parallel.
  • Environments add approval gates, protection rules and scoped secrets before production deploys.
  • Reusable workflows turn common logic into callable, centrally maintained definitions.
Think about it

Mental model

Imagine

A factory floor with interchangeable tool stations

Think of

A GitHub Actions workflow

An event is the order that starts production. Each station (job/step) does one task; some stations run simultaneously (parallel jobs), some only after others finish (needs). The floor supervisor (GITHUB_TOKEN) grants access to materials (secrets) only where needed.

Mechanics

How it works

  • An event (push, pull_request, schedule, workflow_dispatch) triggers a workflow file in .github/workflows.
  • The workflow defines jobs; each job runs in a fresh environment on a runner such as ubuntu-latest.
  • Each job runs steps sequentially — shell commands with run: or marketplace actions with uses:.
  • Expressions like ${{ github.ref }} and ${{ secrets.X }} are evaluated before a step runs, and needs: links dependent jobs.
  • A matrix strategy expands one job across combinations of os/version; the final status reports on the commit and PR.

A workflow run: event, runner, jobs, matrix, results.

GitHub event
Runner
actions/checkout
Matrix jobs
Deploy job
Status check
Reference

Key commands

gh workflow list

List all workflows in the repository.

gh run watch <run-id>

Watch a workflow run until it completes.

gh run view --log-failed

Show only the logs of failed steps in the latest run.

gh run rerun <run-id>

Rerun a failed or partially completed run.

gh pr checks

Show the status of all checks required on a pull request.

Hands-on

Examples

A matrix build with a gated deployment environment

A matrix build with a gated deployment environment
name: CI
on:
  push:
    branches: [main]
  pull_request:
 
jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18, 20, 22]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: npm
      - run: npm ci
      - run: npm test
 
  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production
    steps:
      - run: echo "Deploying with ${{ secrets.DEPLOY_TOKEN }}"

The test job expands into three parallel runs across Node 18, 20 and 22, with npm cached. Deployment waits for all of them, runs only on main, and requires the production environment — so it obeys protection rules and uses production-scoped secrets.

Real world

In production

  • CI gates every PR with lint, test and build jobs; required checks block merges.
  • Main-branch workflows build, scan and deploy to staging; a release tag triggers production.
  • Matrix builds verify compatibility across Node, Python and OS combinations before shipping.
  • Scheduled workflows run dependency updates, security scanning and backups.
  • Environment protection rules require approvals and deploy restrictions for production jobs.
Guidelines

Best practices

  • Pin actions to a commit SHA (or a signed release tag), never to a floating branch.
  • Cache dependency installs with actions/cache or the native cache input of setup actions.
  • Grant GITHUB_TOKEN the minimum permissions for each job's scope.
  • Split large workflows into small jobs joined by needs: so failures are cheap to isolate.
  • Extract repeated logic into composite actions or reusable workflows instead of copying YAML.
Watch out

Common mistakes

  • Hardcoding credentials in workflow files instead of using encrypted secrets.
  • Using unpinned action versions that change behavior without notice.
  • Exposing secrets to pull requests from forks, where untrusted code could exfiltrate them.
  • Building one monolithic workflow with every step, which is slow to iterate and hard to debug.
Root cause analysis

Common issues

Error
File not found on the runner
Root cause

A step expected the repository or a generated file but checkout ran after it, or it was in a different job.

Fix

Run actions/checkout@v4 as the first step, and use upload-artifact and download-artifact to pass files between jobs.

Error
Workflow file is invalid / job failed at validation
Root cause

YAML syntax error, wrong indentation, or an unknown key.

Fix

Validate with a YAML parser and check the workflow's jobs section against the schema; GitHub shows a syntax check in the Actions tab.

Error
403: secrets are not available to this job
Root cause

The job runs for a fork pull request, where secrets are deliberately withheld.

Fix

Use pull_request_target with extreme caution, or gate secret-using jobs to trusted contexts and approved branches.

When things break

Debugging tips

  • gh run view --log-failed jumps straight to the failing step's output.
  • Enable the ACTIONS_STEP_DEBUG repository secret to see masked values and expanded context.
  • Validate YAML and expressions locally with yamllint and act before pushing.
  • Rerun just the failed job (gh run rerun --failed) to avoid rerunning the whole pipeline.
Interviews

Interview checkpoint

Practice

Hands-on lab

Author and Observe a GitHub Actions Workflow
30 min · advanced
In progress
Objectives
  • Create a workflow file with a CI job
  • Commit and push it to trigger a run
  • Query workflow run status via the GitHub REST API
  • Inspect run results without the gh CLI

Author and Observe a GitHub Actions Workflow

30 min · advanced

0/5 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

Where must GitHub Actions workflow files be stored?

2

A matrix strategy runs a single job definition across multiple configured combinations in parallel.

3

How do you safely inject a production credential into a workflow?

Quick reference

Cheat sheet

Workflow building blocks
on:Triggering events
jobs:Top-level job definitions
runs-on:Runner image (ubuntu-latest etc.)
needs:Declare job dependencies
uses: actions/checkout@v4Call an action
Power tools
strategy.matrixRun a job across combinations
environment:Gate with protection rules + secrets
reusable workflowsworkflow_call to reuse YAML
actions/upload-artifactShare files between jobs
if: github.ref == ...Conditional job execution
Go deeper

Official documentation

GitHub Actions documentation
docs
Workflow syntax reference
docs
Reusing workflows
docs
Using environments for deployment
docs