GitHub Actions

This chapter follows Git workflows for teams.

GitHub Actions is GitHub’s built-in automation: run scripts when repository events fire. It complements Git itself—commits still land via git push; Actions reacts afterward for CI, deploys, labeling, and releases. Other hosts offer the same idea under different names, such as GitLab CI/CD with its .gitlab-ci.yml.

Core concepts

Workflows live in the repository, versioned like application code. Pull requests can change CI in the same PR that changes product code—review those diffs carefully.

Minimal workflow

1
name: CI
2

3
on:
4
  push:
5
    branches: [main]
6
  pull_request:
7
    branches: [main]
8

9
jobs:
10
  test:
11
    runs-on: ubuntu-latest
12
    steps:
13
      - uses: actions/checkout@v4
14
      - run: echo "Build and test here"

actions/checkout clones the ref that triggered the workflow (PR merge ref for pull_request events).

A complete Node.js pipeline

Example matching a typical JavaScript repo in this knowledgebase:

1
name: CI
2

3
on:
4
  push:
5
    branches: [main]
6
  pull_request:
7

8
concurrency:
9
  group: ci-${{ github.workflow }}-${{ github.ref }}
10
  cancel-in-progress: true
11

12
jobs:
13
  build:
14
    runs-on: ubuntu-latest
15
    strategy:
16
      matrix:
17
        node-version: [20, 22]
18
    steps:
19
      - uses: actions/checkout@v4
20

21
      - name: Setup Node.js
22
        uses: actions/setup-node@v4
23
        with:
24
          node-version: ${{ matrix.node-version }}
25
          cache: npm
26

27
      - name: Install
28
        run: npm ci
29

30
      - name: Lint
31
        run: npm run lint --if-present
32

33
      - name: Test
34
        run: npm test
35

36
      - name: Build
37
        run: npm run build --if-present

npm ci assumes a lockfile. --if-present skips scripts your package.json does not define. concurrency cancels outdated runs on the same branch when new commits arrive.

Secrets and environments

Store tokens in Settings → Secrets and variables → Actions. Reference them as ${{ secrets.MY_TOKEN }}—GitHub masks values in logs. Never commit secrets into workflow YAML.

Environments (for example production) add approval gates and environment-scoped secrets for deploy jobs:

1
jobs:
2
  deploy:
3
    needs: build
4
    runs-on: ubuntu-latest
5
    environment: production
6
    steps:
7
      - run: ./deploy.sh
8
        env:
9
          DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}

Caching dependencies

actions/setup-node with cache: npm (or pnpm, yarn) speeds installs. For custom paths use actions/cache:

1
- uses: actions/cache@v4
2
  with:
3
    path: ~/.npm
4
    key: npm-${{ runner.os }}-${{ hashFiles('package-lock.json') }}

Reusable workflows and composite actions

Split org-wide CI into callable workflows:

1
on:
2
  workflow_call:
3
    inputs:
4
      node-version:
5
        required: true
6
        type: string
7
jobs:
8
  test:
9
    runs-on: ubuntu-latest
10
    steps:
11
      - uses: actions/checkout@v4
12
      - uses: actions/setup-node@v4
13
        with:
14
          node-version: ${{ inputs.node-version }}
15
      - run: npm ci && npm test

Caller:

1
jobs:
2
  call:
3
    uses: ./.github/workflows/reusable-test.yml
4
    with:
5
      node-version: "22"

Status checks and branch protection

Job names appear as status checks on pull requests. Tie branch protection to required checks so main cannot merge until CI passes.

Self-hosted runners

Self-hosted runners execute on your hardware—useful for private networks, larger machines, or specialized hardware. You register the runner with the repo or org and label jobs with runs-on: [self-hosted, linux]. Patch and isolate runners; they execute arbitrary workflow code.

Where Actions fits in the series

Git records history; Actions validates and ships it. Combine protected main, PR review, and a workflow like the Node example above for a baseline pipeline many teams use before adding deploy stages.

This is the last chapter in Git and GitHub. Reference pages: Git cheat sheet and Git glossary.