Github Actions for .NET: Build, Test, and Ship With Docker

You just pushed your code, and now you wait.

Did the build pass? Did the tests run? Is the Docker image ready to ship?

If you are checking these by hand, you are doing work a machine should do for you.

A good CI/CD pipeline builds, tests, and ships every change the same way, every time - without you babysitting it.

Over the years, I have set up these pipelines for many .NET projects, and GitHub Actions has become my default.

It lives right next to your code, it is free for most projects, and it can take a single commit all the way from a pull request to a published Docker image.

In this post, we will explore:

• What are GitHub Actions
• Building and testing your .NET app
• Publishing a NuGet package after tests pass
• Building a Docker image that runs tests
• Setting up secrets in GitHub Actions
• Pushing the Docker image to the registry

Let's dive in.

What Are GitHub Actions?

GitHub Actions is a built-in automation platform inside every GitHub repository.

You describe what should happen when something occurs in your repository - a push, a pull request, a new tag, a schedule or manual - and GitHub runs it for you on a fresh virtual machine.

You need to know these terms to be able to read any workflow:

• Workflow: an automated process defined in a YAML file under .github/workflows. A repository can have many.
• Event: what triggers a workflow - a push, a pull_request, a release, or a schedule.
• Job: a group of steps that runs on one machine. Jobs run in parallel by default, or in order when one needs another.
• Step: a single task - either a shell command (run) or a reusable action (uses).
• Runner: the machine that executes a job. GitHub hosts Linux, Windows, and macOS runners, and you can host your own.

Any workflow in GitHub Actions is a series of steps that run on a virtual machine.

With these, you can automate almost anything related to your code: run tests on every pull request, publish a NuGet package with a new release, build and push a Docker image, run a nightly security scan, or post a message to Slack.

Because a workflow is just a file in your repository, it is versioned with your code and reviewed in pull requests like everything else. The pipeline evolves together with the application it builds.

Every workflow is a single YAML file. Here is the smallest one that does real work - it runs on each push to main and prints a line on an Ubuntu runner:

name: HELLO

on:
  push:
    branches: [ "main" ]

jobs:
  hello:
    runs-on: ubuntu-latest
    steps:
      - run: echo "GitHub Actions is running"

Save this as .github/workflows/hello.yml, push it, and open the Actions tab in your repository to watch it run.

---

👉 Read the full article on my newsletter: https://antondevtips.com/blog/github-actions-for-dotnet-build-test-and-ship-with-docker