GitHub Actions

Every team has a set of checks that should pass before a change is accepted: it builds, the tests pass, the formatter has been run, nothing obvious is broken. Relying on each person to remember means it holds until the afternoon somebody is in a hurry.

GitHub Actions runs those checks for you, on GitHub's machines, triggered by events in the repository. You describe what to run in a file, commit the file, and from then on every push and every pull request gets the same treatment. Running checks automatically on every change is usually called continuous integration, shortened to CI.

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest

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

      - name: Install the .NET SDK
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: "8.0.x"

      - name: Restore dependencies
        run: dotnet restore

      - name: Build
        run: dotnet build --no-restore --configuration Release

      - name: Run tests
        run: dotnet test --no-build --configuration Release

• The on: block declares two triggers. push with branches: [main] runs the workflow when commits land on main. pull_request runs it against the proposed merge result every time the branch is updated, which is the one that protects main.
• runs-on: ubuntu-latest asks for a Linux runner. The job starts on a clean machine, which is why the first step has to fetch your code.
• uses: refers to a published action. checkout copies your repository onto the runner; setup-dotnet installs the SDK. Action versions move over time, so check the action's own repository for the current major version rather than copying one from an old example.
• run: executes a shell command. Any non-zero exit code fails the step, fails the job, and marks the check as failed on the pull request.
• --no-restore and --no-build tell the later steps not to repeat work the earlier ones did. Matching --configuration across build and test matters: mismatch them and the test step rebuilds, which is slower and quietly defeats --no-build.
• Set dotnet-version to match what your project targets. A workflow that builds against a different SDK than your team uses locally will eventually disagree with them.

git switch -c add-ci-workflow

# Create .github/workflows/ci.yml, then:
git add .github/workflows/ci.yml
git commit -m "Run build and tests on every push and pull request"

git push -u origin add-ci-workflow

# Open a pull request. The workflow runs against this very branch,
# so the pull request itself tells you whether the workflow works.

• The workflow file is committed like any other file, which means it is versioned, reviewable and revertable. A change to the build process goes through review the same way a change to the code does.
• The path matters. GitHub looks for workflows in .github/workflows, and a file anywhere else is ignored with no error message.
• Opening a pull request is the quickest way to test a new workflow, because the pull_request trigger applies to the branch adding it.
• Expect two or three attempts before it passes. A workflow runs on a clean machine with none of the tools your own machine has accumulated, and the first failures are usually something you had installed and forgot about.