This lesson's interactive features are locked, please to keep using them

Breakdown of GitHub Actions

Let's break down some of the concepts from the workflow file we created.

name: ci

on:
  pull_request:
    branches: [main]

jobs:
  tests:
    name: Tests
    runs-on: ubuntu-latest

    steps:
      - name: Check out code
        uses: actions/checkout@v6

      - name: Set up Node
        uses: actions/setup-node@v5
        with:
          node-version: 22

      - name: Force Failure
        run: (exit 1)

Workflows

A workflow is triggered when an event occurs in your GitHub repository. For example, we'll trigger our "tests" workflow when we open a pull request into the main branch.

In our case, the ci.yml file contains a single workflow called "ci", but we could have named it anything.

Jobs

A workflow is made up of one or more jobs. A job is a set of steps that run on the same runner, which is just a virtual machine that runs your job on GitHub's servers.

For now, we just have one job. You would typically have multiple jobs if you wanted to run your tests in parallel, or if you wanted to run your tests on multiple operating systems.

In our case, the ci.yml workflow contains a single job called "Tests".

Steps

A job is made up of one or more steps. A step is a single task that can run commands, a script, or an action. For example, the steps of a job might include:

Checking out the code
Installing dependencies
Running tests

In our case, the "Tests" job contains 3 steps:

Check out the code
Set up Node
Force failure of the CI job

Assignment

Update the last step of the job to run node --version instead of (exit 1). That command should just print the current version of Node and exit with code 0. Give the step a new name. Commit and push the changes, and your CI job should pass!

A workflow that triggers on pull requests will re-run when the branch to be merged is updated.

Paste the URL of your GitHub repo into the box and run the GitHub checks.