devops

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
blankRepo

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).
test_run

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.

netcore-wf

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.

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

building

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](https://github.com/paulthecyclist/CIDemo/workflows/CI%20Build/badge.svg)

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:
Badge

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

 

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.

step1

 

 

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

step2

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

step3

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

step4

 

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

step5
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

step6

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.

step7

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 **\*

step8

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

**\$(BuildConfiguration)\*test*.dll;-:**\obj\**

to:

$(Build.StagingDirectory)\*test*.dll;-:**\obj\**

Which looks like this

step9

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

step10

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

step11

Then the build starts

step12

…and succeeds!

 

step13

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.

step14

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.