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

Continuous Integration

Continuous Integration (CI) is where developers regularly push code changes into a central repository, and by doing so, automated builds and tests are automatically run.

Those tests can include unit tests, integration tests, styling checks, linting checks, security checks or any other type of automated test. If any of the tests fail, the build is considered "broken" and the developer is notified so they can fix it.

Click to play video

Our Internal CI at Boot.dev

Here at Boot.dev we have CI tests that run each time a new pull request is opened. The reviewer doesn't need to manually check for formatting issues or run tests locally before approving the changes. It automates part of the code review process.

CI is all about automating as much of the testing and review process as possible.

Assignment

While still on the addtests branch, create a new .github directory in the root of your repository
Create a new directory inside .github called workflows
Create a new workflow by adding a file called ci.yml inside .github/workflows:

Make sure you use the .yml extension. .yaml is valid, but we test for .yml.

GitHub Actions workflows are written in YAML, and GitHub automatically checks for and runs workflows in the .github/workflows directory of your repository.

Open ci.yml in your editor and add the following:

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 Go
        uses: actions/setup-go@v6
        with:
          go-version: "1.26.0"

      - name: Force Failure
        run: (exit 1)

By default, a step "succeeds" if it exits with a status code of 0 and "fails" if it exits with a status code other than 0.

Every (good) CLI tool that I'm aware of follows the convention of exit code 0 = pass, anything else = fail. For example, if a test case fails, go test will exit with a status code of 1.

Don't worry, I'll explain each line of the workflow file in detail soon.

Let's make sure that our CI tests fail when our tests fail. The last step of our workflow file is:

- name: Force Failure
  run: (exit 1)

This step always fails because it runs the command exit 1, which exits with a status code of 1.

Commit and push your changes up to your remote branch. Then, on your pull requests page, you should see that the "tests" workflow runs and fails. Great! That means that our (very basic) CI is working.

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