Recently those clever people at GitHub released Github Actions, offering the ability to automate your workflows behind the scenes in addition to their existing GitHub features. In a nutshell it lets you attach a trigger (e.g. a Push) to an action (e.g. build). You can create your own or pick one from the market place. Pricing is great – completely free for public repos and 2000 minutes per month for private. I have been working with Azure Devops recently and there are definitely some parallels between the two – like Azure Pipelines, Github Actions uses yaml files to define actions. A nice comparison can be found here.
Earlier this week I thought I’d have a little play with it to answer my question of how easy would it be to get a basic CI setup (build and run tests) for a new .Net Core project.
Create and populate a gitHub repo
Create a blank repo in Github
Clone this to get a local directory connected to your GitHub account. Open up a command prompt/bash terminal and change directory to your newly created directory. From here I’m assuming you have .Net Core and GIT installed.
- Create a .Net solution
- Create a Business Logic project and one Tests project
- Reference the business class in the tests project
- Add both projects to the sln:
dotnet new sln dotnet new classlib -o Business dotnet new xunit -o Tests dotnet add Tests\Tests.csproj reference Business\Business.csproj dotnet sln add Business\Business.csproj Tests\Tests.csproj
Build it locally
dotnet restore dotnet build
Run the Tests (one comes for free in the XUnit project).
Commit and push it to GitHub
git add . git commit "Adding csharp projects" git push origin
Now in GitHub we have a repository with some csharp files.
Hello, GitHub Actions
Our goal is to build and test our solution when we push files into the repo. To achieve this we are going to use a .Net Core action from the market place.
In GitHub, go into your repository and choose the Actions link. There are quite a few starter workflows to choose from – find the .Net Core one and click the Setup this workflow button.

This will create a yaml file for you with a default .Net Core Build and Test workflow. If you are familiar with Azure Devops this will be very readable. The only change we are going to make is to the name – I’m going to call mine: CI Build.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
name: CI Build | |
on: | |
push: | |
branches: [ master ] | |
pull_request: | |
branches: [ master ] | |
jobs: | |
build: | |
runs-on: ubuntu-latest | |
steps: | |
– uses: actions/checkout@v2 | |
– name: Setup .NET Core | |
uses: actions/setup-dotnet@v1 | |
with: | |
dotnet-version: 3.1.101 | |
– name: Install dependencies | |
run: dotnet restore | |
– name: Build | |
run: dotnet build –configuration Release –no-restore | |
– name: Test | |
run: dotnet test –no-restore –verbosity normal |
When you are happy with this, commit it.
As soon as this has been committed you’ll have a workflow with a trigger for when new files are pushed; by adding this file into our repo a build will have been triggered.
Navigate to your Actions to view the build (live progress) or the resulting log:
https://github.com/paulthecyclist/CIDemo/actions?query=workflow%3A%22CI+Build%22

As this is sweet, sweet, demo code that does nothing, we get lots of green ticks.
Add a Status Badge
To see the build status as soon you navigate to your repo, we can add a status badge to the ReadMe.
The mark down looks like:

You can browse directly to that url to preview the badge – recommended!
Breaking the url down it’s github.com/ {username} / {repo} / workflows/ {Action Name} / badge.svg
If successful you should see:
This can now be auto generated from the action web page – where there is a handy Create Status Badge button, which will generate the markup for you.
Thoughts
I like this – it really did just work and it’s fast; the build/test time was quick but also very little time spent in a queue waiting on the agent virtual environment before the action was triggered.
All of the above code can be viewed in my GitHub Repo:
https://github.com/paulthecyclist/CIDemo