Github Actions has been released for public use, and announced at the Github Universe conferense in San Franciso Nov. 13th. And, because Github loves open source - it is fully free for all public repositories!
Github Actions can be used for automating a series of processes, as it can utilize most of the events in the github system. The most typical use will still be to trigger CI/CD builds. The whole system is yaml based, and it can run on different environments, Linux, Windows and MacOS.
There also is a marketplace where you can find a lot of community contributed actions to be used in your workflow.
You can also find a series of starter workflows which you can use for your first builds. As they are written in yaml, they are easy to customize to your needs. A good introduction to yaml can be found here. When you press New Workflow on the Actions page ((1) in screenshot below), you get a list of proposals, or you can start out blank ((2) in screenshot below)
If you add a github action for the first time using the web interface, you will see that the file is placed in the .github/workflows folder.
Note that if want to edit this file locally, you need to have a SSH enabled local repo. See Connecting to GitHub with SSH
We're using a simple test project based on .net core. The repository is named ActionExample1
We start off by using the standard .Net Core starter workflow. We then modify the file to add unit testing (3) - it is not there by default yet (I have added a PR for that, but not yet approved and merged). We also change the name to something meaningful (1), including the filename. Just for fun we also change from running on ubuntu to windows (2) . .Net Core can run on both, so....
As you can see the build file is very small, and easy to understand.
And when it has run, successfully of course, the details look like shown below:
The build system for the NUnit3TestAdapter is based on a Cake script that is started off by a powershell script.
To set that build off doesn't require much:
and the results look like:
To build .net framework projects we must check out whether it uses the old legacy project format, or the new SDK based format. Many projects, or most now, can use the new SDK format. See this blogpost for how to convert your project automatically to the new SDK format from the old legacy format.
Using the new SDK project format makes it much simpler to build, because you can then use the dotnet system, which encapsulates all the other stuff you need.
If you have to stay on the old legacy format, you must use the msbuild system.
I will now show how you do both.
The repo with an SDK format .net project needs a slightly modified workflow, based on the starter-workflow Dotnet Core.
As you can see, the workflow is functionally identical to the .net core workflow above. We can still use dotnet to build the .net framework project, because it uses the SDK format, and we can test it using dotnet test.
And as can be seen, it builds just fine:
The DotNet Core 'dotnet' tool can not build projects using the old legacy format. So we then have to resort to good old msbuild. And that also means that running tests are not so simple anymore, so we keep that out for now (until you have moved over to the SDK format, and the problem just disappears).
For this example, I will use the Example 3 repository.
For such a project, there is no starter workflow available (as of writing Nov 2019), so will start with an empty workflow:
The "empty" is not that empty, so just delete whatever is in the script, and replace with the gist NetFramework.Legacy.CI.
Then give it a nice name, and replace YOUR_SOLUTION_NAME in the gist to the correct name and path for your solution.
And running this build gives:
Credit: This gist uses actions provided by Warren Buckley
Building .Net Framework projects are easy with Github actions, but if you're using the legacy project format, you should first try to migrate to the new SDK format.
