Continuous integration and continuous delivery (CI/CD) is the practice of automating how code is tested, built, and deployed every time it changes. GitHub Actions is GitHub's native CI/CD platform — and since GitHub hosts the majority of the world's open source code, GitHub Actions has become the most-used CI/CD platform in the industry.
Why Actions Won
Before Actions, teams ran CI/CD on separate platforms — Jenkins, CircleCI, Travis CI, GitLab CI. Each required separate configuration, separate auth, and separate UI. GitHub Actions, launched in 2018 and generally available in 2019, solved this by putting the pipeline definition next to the code itself:
- Workflows are YAML files in
.github/workflows/in your repo - The same pull request that changes code can change its CI pipeline
- Logs and status checks appear directly in the GitHub PR UI
- An ecosystem of pre-built actions covers nearly every common task
The Execution Hierarchy
| Concept | What it is |
|---|---|
| Event | Something that triggers a workflow — push, pull_request, schedule, workflow_dispatch, etc. |
| Workflow | A YAML file describing what to do when an event fires |
| Job | A unit of work in a workflow, run on a single runner |
| Step | A single shell command or invocation of an Action |
| Action | A reusable, packaged unit of automation (e.g., actions/checkout) |
| Runner | The virtual machine or container that executes a job |
A Minimal 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
That is the entire pipeline for a typical Node.js project. Save the file to .github/workflows/ci.yml, push it, and every subsequent push or PR runs your tests automatically.
How a Run Plays Out
- An event occurs (a push, for example)
- GitHub matches the event to one or more workflow files
- For each matched workflow, GitHub queues the jobs
- Each job is dispatched to a fresh runner — a clean VM by default
- The runner executes the steps in order
- Logs stream back to the GitHub UI in real time
- The job's success or failure becomes a status check on the commit/PR
What You Can Automate
The "CI" in CI/CD is just the start. Common workflow purposes:
- Run unit/integration tests on every PR
- Build container images and push to a registry
- Deploy applications to AWS, Azure, GCP, Vercel, Cloudflare, etc.
- Generate releases with auto-changelog
- Run security scans (CodeQL, Dependabot, Trivy)
- Sync issues to project boards
- Automatically label PRs and triage issues
- Schedule recurring data jobs
- Build and publish documentation sites
Pricing in 2026
| Plan | Included minutes/month (private repo) | Public repos |
|---|---|---|
| Free | 2,000 | Unlimited |
| Pro / Teams | 3,000 | Unlimited |
| Enterprise | 50,000 | Unlimited |
Minutes are charged differently per runner type: Linux 1×, Windows 2×, macOS 10×. Self-hosted runners cost zero minutes.
Where Actions Sits in the Toolbox
Actions does not replace every devops tool — it orchestrates them. Inside a workflow you still call docker, terraform, kubectl, aws, az, or any other CLI. Actions provides the trigger, the runner, the secrets handling, and the logging — the work itself is still done by the underlying tools.
In the next lesson, we dissect the YAML syntax used to express these workflows.