What is GitHub Actions?
GitHub Actions runs automation directly from your repository, triggered by events like a push or a pull request. You describe workflows in YAML; GitHub spins up runners to execute the jobs. It is the most common CI/CD system for projects hosted on GitHub.
Why it matters
CI/CD is core DevOps, and Actions is where most teams build it because it lives next to the code. Knowing how to write workflows — test on every PR, build and deploy on merge — is a direct, daily skill. The same model transfers to other CI systems.
What to learn
- Workflows, jobs, steps, and triggers
- Hosted vs self-hosted runners
- Actions from the marketplace, and pinning their versions
- Secrets and environment protection
- Caching dependencies and build artifacts
- Matrix builds across versions
- Conditionals and job dependencies
Common pitfall
Using third-party actions pinned to a mutable tag like @v3 or @main. The
code behind that tag can change under you, and a compromised action runs with
access to your secrets. Pin actions to a full commit SHA for anything that
touches credentials, so the code cannot change silently.
Resources
Primary (free):
- GitHub Actions — Documentation · docs
- GitHub Actions — Workflow syntax · docs
- GitHub Actions — Security hardening · docs
Practice
Write a workflow that runs on every pull request: install dependencies with caching, lint, and test. Add a second job that builds a Docker image and runs only on push to main, using a secret for the registry. Pin every third-party action to a SHA. Done when a failing test blocks the PR.
Outcomes
- Write workflows triggered by repository events.
- Cache dependencies and use a build matrix.
- Handle secrets and protected environments safely.
- Pin third-party actions to a commit SHA.