GitHub Actions, meet .Net Core

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.

name: CI Build
branches: [ master ]
branches: [ master ]
runs-on: ubuntu-latest
uses: actions/checkout@v2
name: Setup .NET Core
uses: actions/setup-dotnet@v1
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

view raw


hosted with ❤ by GitHub

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:


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:

![CI Build](

You can browse directly to that url to preview the badge – recommended!
Breaking the url down it’s {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.


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:



Continuous Integration and Delivery with Visual Studio Team Services (Part 2)

This post follows on from part 1, where I walked through the creation of the CI part of our pipeline,  creating a Visual Studio Team Services build definition that was triggered by a checkin to our GIT repository. This the CD part.

The goal is to deploy automatically after build our .Net MVC website.

I’m going to start, in Visual Studio Team services, going into my project Binet and clicking on the releases tab. As we have no releases yet, it should look a bit like:


Let’s create a new release definition – we now see the following dialogue.


We just want a basic deploy of our code to an Azure website for this demo. Azure App Service Deployment is good for us. The other Azure App Service deployments are fun too, but maybe another time. Hit Next and now we’re creating a release definition. This is based on our build from earlier (unimaginatively called standard build). Choose this Standard build and check the continuous deployment box – that’s the whole point of this!


Next it will take you to the environments tab. A complicated looking tab to choose a source and destination is how I like to think of it. Here we need to pick our subscription, and the name of the app service we want to deploy to, we’ll call it binet.


As this is was my first time I also needed to hit authorise, when choosing my subscription; I don’t pretend to understand the consequences of this, other than you gotta do it.


We also need to setup our source. This is the Package or folder part. By clicking the ellipsis we can select the (_PublishedWebsite) folder that was output in step 1 of the process and select the folder immediately under this, where our website files exist.


The path that we’ll end up selecting is:
$(System.DefaultWorkingDirectory)/Standard Build/drop/_PublishedWebsites/NextFib

Hit save and our release definition is complete. Let’s force it to run manually to test if we did it right or not; choose create a release from the Release tab that’s against the release definition.


This will bring up another dialogue, where you can pick a particular build to deploy. By default it’s displaying the latest build (number) available – this is the one we want. So accept these defaults and hit create.


Much like the creating of a build, your request will be queued up and picked up as soon as an agent is ready. For me, a mere few seconds later and an agent picked up my request and the deployment build began.


After a couple of mins it finished and… it failed. If things worked first time, how could you learn? Helpfully? I also received an email telling me about what a failure I am.


Big plus here, is a very clear error message (way better than msbuild exited with code 1). It turns out you need to create an instance of the App Service in the subscription you picked in order to deploy to it. Doh! An easy problem to fix though. I hopped over to my Azure Portal and create an empty App Service entry named binet


Let’s try that deploy again. Going back to visual studio team services, navigate to releases and kick one off again. This time…



Yes – deployment was successful!
My website showcasing Binet’s forumla is now live and being hosted in Azure. Go check it out.



After this I performed a couple of minor updates to the site, checked them into Github and verified that the CI worked and the CD deployed to the Azure App Services website. I appreciate this is a very simple example, but is one that can be built on. What I do like about this solution is having my entire infrastructure in the cloud; also it’s cost me nothing!

Continuous Integration and Delivery with Visual Studio Team Services (Part 1)

How easy it is to use TFS online (aka Visual Studio Team Services) to build, run unit tests and deploy a simple.Net MVC website into Azure websites? This post is part 1 – building, running tests and creating the artifacts. Part 2 will look at using MS Release Management (part of VSTS too) to take the build output and deploy it to Azure websites. The goal is that when I check in my code, Visual Studio Team Services will compile it, test it and then deploy.

Recently I used the Visual Studio Team Services tooling to achieve CI and CD, and to my surprise it was quick and actually, reasonably pain free to setup. I was so pleased, I thought I’d write a couple of blog posts about it.

I created a simple .Net solution, that consisted of 3 projects.

  1. MVC Website
  2. Test Project
  3. Class Library

The website is a simple implementation of Binet’s formula to calculate the nth item in the Fibonacci sequence. Not important right now and I’ll go into the website side of things more in a subsequent post. I hooked it into a github repository, got it working and committed it.

Now the interesting part begins, of getting Visual Studio Online Visual Studio Team Services to create the build.

Step 1 – Go to Visual Studio Team Services, sign in/create a free account and create a new project, calling it Binet, selecting GIT as the source control.




Hit Create. Next we need to connect it to our GIT repsoitory.  As our code is already hosted at GitHub, choose setup build.


Next – we’re creating a build definition, online. Exciting times. From the options available we want to use the Visual Studio template.


Hit Next. Now we need to connect the build definition to our github repository. All other defaults remain.



For me, this popped out a new tab asking me to connect my VS online account to my GitHub account.

Small gotcha for me – hitting the authorize button tried to create a popup that chrome blocked, so had to allow this popup).

Allow VS Online access to my github account


I then selected my Binet respository, came back to VS Online and hit save, and we’re done! We have a complete build definition using virtually all the default settings.

Well, not quite. It won’t create the website in the artifacts folder. What the duce…
Yes, the most important part of building a website, is, well the website! By default it was creating just the test and class library project.

There is a solution though. This blog, details it.
The gist is we need to get msbuild to create the infamous _PublishedWebsites  folder, which contains all the files the website needs. This is achieved by passing these magic commands to msbuild:

/p:OutDir=$(build.stagingDirectory) /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true

Navigate to the build definition, and change the msbuild arguments passed into the ‘Build Solution step.


We want to make sure we publish all files to the artifacts directory, so we need to make a small change to the Copy files step. This is changing the contents to **\*


Nearly there. As we have a moved the output slightly, we need to update the test step to be able to locate the test assemblies now. That involves changing the entry for test assembly from




Which looks like this


Now we are ready to try it. Hit the Queue new build button. I just accepted the default options and hit ok.


and we’re off and waiting for a build agent. For me this didn’t take very long at all.


Then the build starts


…and succeeds!



We can also look at the stats of the build, in the build summary. From here you can also view the artifacts to verify what was built.


We now have an active build definition set up in Visual Studio team services. Every time a checkin is detected on our Github repository a new build is triggered.

In my next post I’ll show how to setup continuous delivery to Azure websites using the online Release Management tooling.