GitHub Actions Basics: One CI Check You Can Trust
CI only matters if it runs something real. Most tutorials show either bloated pipelines or toy examples that verify nothing. I prefer one workflow, one runner, two commands, and a green check.
This post is the workflow file I use as a baseline.
Why I set this up first
Without CI, I am the only person verifying the build. The moment another OS, another Node version, or another contributor enters the picture, assumptions break. CI gives me feedback in a clean environment every time I push.
GitHub Actions is just the platform. It spins up a temporary machine, checks out my code, runs the commands I tell it to run, and reports pass or fail. Nothing more mysterious than that.
The workflow file
Create .github/workflows/ci.yml:
name: CIon:push:branches: ["main"]pull_request:branches: ["main"]jobs:build:runs-on: ubuntu-lateststeps:- uses: actions/checkout@v4- uses: actions/setup-node@v4with:node-version: 20- run: npm install- run: npm run lint- run: npm run build
That is it. actions/checkout pulls the repo. actions/setup-node installs Node. The three run lines execute the same commands I run locally. If any exit non-zero, the workflow fails.
How I verify it works
I commit the file, push to GitHub, then open the Actions tab. If the run is green, CI is working. If it fails, the log tells me exactly which command failed. I fix it locally, commit again, and CI re-runs.
Common failures I have hit
- Workflow never runs: the default branch is not named
main. - Install fails:
package-lock.jsonis missing or out of sync. - Passes locally, fails in CI: local environment hides an assumption, like a different Node version or a missing env var.
The fix is always to make local and CI more similar, not to weaken the checks.
Closing
A CI setup is not measured by complexity. It is measured by whether it runs my real build in a clean environment and tells me when something breaks. If I have a workflow file, a visible run, and a green check, CI is doing its job.