Git
Advanced 16 min read Git

GitHub Actions & CI/CD

GitHub Actions automates CI/CD inside GitHub using workflows defined in .github/workflows. Events trigger jobs on runners; jobs run steps that call actions like actions/checkout. Learn events, matrix builds, secrets, caching and artifacts to build production-grade pipelines.

workflowjobsteprunneractions/checkoutmatrixsecretsartifacts
Introduction

What is this?

GitHub Actions is a CI/CD platform built into GitHub. Workflows are YAML files in .github/workflows that define jobs and steps. They are triggered by events such as push, pull_request or schedule, run on hosted or self-hosted runners, and can build, test, deploy, and report status back to the pull request.

Motivation

Why do you need it?

  • CI/CD lives in the same system as the code, so every push and pull request gets checks automatically.
  • Reusable, versioned actions let you compose pipelines from community building blocks.
  • Matrix builds run the same job across OSes and versions in parallel.
  • Tight integration with PR review: required checks gate merges.
Think about it

Mental model

Imagine

An assembly line

Think of

A GitHub Actions workflow

An event starts the line; each station (job/step) does one task; parts (artifacts) move along; the QA gate (tests) decides whether the product ships.

Mechanics

How it works

  • An event (e.g. push or pull_request) triggers a workflow file in .github/workflows.
  • The workflow defines jobs, each of which runs on a runner such as ubuntu-latest.
  • Each job runs steps sequentially — either shell commands (run:) or community actions (uses:).
  • needs: creates dependencies between jobs, so a deploy job can wait for tests to pass.
  • Secrets are injected via secrets.X and never appear in logs; artifacts are uploaded for later steps or downloads.
  • The final status is reported on the commit and the pull request as a check.

Anatomy of a GitHub Actions workflow run.

GitHub event
Runner
actions/checkout
Build + test
Upload artifact
Status check
Reference

Key commands

git push origin main

Pushing to main triggers workflows configured for push events.

gh workflow list

List workflows in the repository with the GitHub CLI.

gh run watch <id>

Watch a workflow run until it finishes.

gh run view --log-failed

Show only the failing steps of the latest run.

gh pr checks

Show the status of all checks on a pull request.

Hands-on

Examples

A minimal CI workflow

A minimal CI workflow
name: CI
on:
push:
branches: [main]
pull_request:
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
- run: npm ci
- run: npm test

This workflow runs on every push to main and every pull request. It checks out the code, installs Node 20, installs dependencies with npm ci, and runs the test suite. A failure blocks the PR from merging.

Real world

In production

  • CI: lint, test and build on every pull request, gating merges with required checks.
  • CD: deploy to staging on push to main and to production on a release tag.
  • Matrix builds verify an app across Node versions and operating systems.
  • Scheduled workflows run security scans, dependency updates and database backups.
Guidelines

Best practices

  • Pin actions to a tag or commit SHA, never to a floating branch like @main.
  • Cache dependency installs with actions/cache to cut run time.
  • Store credentials in repository secrets and reference them as secrets.X.
  • Use small, focused jobs with needs: dependencies so failures are easy to isolate.
  • Reuse logic with composite actions or reusable workflows instead of duplicating YAML.
Watch out

Common mistakes

  • Hardcoding tokens or passwords directly in workflow files.
  • Using unpinned action versions (uses: user/action@main), which can change behavior overnight.
  • Running untrusted pull request code with access to secrets (forks).
  • Building one giant monolith workflow that is impossible to debug or reuse.
Root cause analysis

Common issues

Error
No such file or directory when reading source files
Root cause

A step expected the repository to be present but checkout did not run first.

Fix

Add - uses: actions/checkout@v4 as the first step of the job.

Error
Problem with this workflow file: 'jobs' must not be empty
Root cause

YAML syntax error or wrong indentation.

Fix

Validate with yamllint or a YAML parser before pushing, and check indentation of jobs/steps.

Error
403 Resource not accessible by integration
Root cause

A protected branch rejected the push or the job lacks permission.

Fix

Open a pull request instead of pushing to the protected branch, or grant the required permissions.

When things break

Debugging tips

  • gh run view --log-failed to jump straight to the failing step.
  • Rerun failed jobs with gh run rerun <id> or the Actions tab.
  • Set the repository secret ACTIONS_STEP_DEBUG to true to enable step debug logging.
  • Validate workflow YAML locally with yamllint before pushing.
Interviews

Interview checkpoint

Practice

Hands-on lab

Build a CI Pipeline with GitHub Actions
35 min · advanced
In progress
Objectives
  • Create a workflow file in .github/workflows
  • Trigger CI on push and pull_request
  • Add a matrix build across Node versions
  • Cache dependencies and inspect run logs

Build a CI Pipeline with GitHub Actions

35 min · advanced

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

Quick quiz

0/3
1

Where are GitHub Actions workflow files stored?

2

GitHub Actions workflow files must be named main.yml.

3

Which action clones the repository into the runner?

Quick reference

Cheat sheet

Key YAML keys
name:Workflow name
on: [push]Triggering events
jobs:Top-level job list
runs-on: ubuntu-latestRunner image
needs: [test]Job dependency
uses: actions/checkout@v4Call an action
run: npm testRun a shell command
secrets: ${{ secrets.X }}Inject a secret
Go deeper

Official documentation