GitHub Actions runs scripts in your repository automatically, in response to events like a push or a pull request. It can run tests, build your app, or deploy it wherever you like. Once you write a workflow file, the work repeats itself on every relevant change, no one has to remember to run it by hand.
About 2 min of reading
Before this new lesson, one small question about the lesson you just finished. Recall it, do not look it up.
I used to run tests by hand before every merge, then forgot once and shipped something broken. Let me write my first workflow file that runs the tests automatically on every push, so the pipeline does the work and a red mark on the PR does the catching.
First, make sure your project has something to run. A workflow only works if there is a test or build command it can invoke. Check the package.json for a test script so you know what to put in the workflow.
Before you run it, say out loud what it will print. Then open the answer.
Create the workflow file in .github/workflows/. The name is a label you read later, the on line is the trigger that starts it, and the job runs on a fresh machine every time. This is the smallest possible automation: run the tests whenever someone pushes.
Before you run it, say out loud what it will print. Then open the answer.
Push the workflow file. GitHub reads it automatically and runs the job on its first push, so there is nothing to deploy or configure. The test job runs on a fresh machine, checks out the code, then runs npm test.
Before you run it, say out loud what it will print. Then open the answer.
Open the Actions tab and watch it run. The first run shows the job, the steps, and a green or red result. If npm test passed, every step is green. If it failed, the last step is red and you can click it to see exactly which test failed, no need to run it by hand yourself.
Before you run it, say out loud what it will print. Then open the answer.
Now the tests run on every push without anyone remembering. If a future push breaks the tests, that red mark on the PR shows before the merge, and it is enough to make someone investigate first. The work repeats itself; you only have to react when it turns red.
Before you run it, say out loud what it will print. Then open the answer.
Before you write anything, put these lines back in the right order. Click a line to move it up one step. This support step is easier than writing code from scratch, and it is here to make the last example stick.
A workflow starts when an event fires, a push, a pull request, a schedule. Set the trigger so it runs exactly when it needs to; a wrong trigger is the most common reason an automation seems to 'not work'.
A job runs on a machine and is made of steps. Each step is a command. One workflow can have many jobs, and they can even run in parallel, which is useful when you have independent things to test.
name: CI
on: [push]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm testNow every push runs npm test, and if it fails the pull request shows a red X. Nobody remembers to run tests and nobody forgets, the pipeline does it. That red mark on a PR is usually enough to make someone investigate before they merge.
jobs:
test:
strategy:
matrix: [node-18, node-20, node-22]
runs-on: ubuntu-latest
steps:
- run: npm testApps often need to run on several platforms, and checking each one by hand is tedious. A matrix lets a single job run them all at once. The report shows exactly which version passed and which failed, so you can chase the specific problem.
name: Nightly
on:
schedule:
- cron: '0 2 * * *'
jobs:
backup:
runs-on: ubuntu-latest
steps:
- run: echo "Running backup"The 0 2 * line means every day at 2 AM. Great for backups, reports, or checking for stale issues while the lights are off. Some jobs should simply run on a schedule, and cron makes that trivial.
Each one is defined here on this site. Open the entry for the full definition and the other words it points at.