Article by Ben Wilson of Rivers Agile
In Part 1 of this series, we explained how to integrate Github Actions into your CI process. Now, let’s try creating a real example. For Part 2, we’ll be using a simple DotNet Core 3.1 project called “DoctorWhoAndWhen”. With this project, you can use an actor’s name and return the years they portrayed ‘the Doctor’ on the TV show “Doctor Who”. Alternatively, it can use a given year and return all actors who portrayed ‘the Doctor’ in that year. Our project will be stored in this GitHub repository. For Part 2 of this blog series, we’ll be using the basic workflow test branch, which will be preserved to match this post.
Over the course of Parts 2 and 3, we will be creating Actions that do the following:
We’ll have three actions in total when we’re done.
The first action will run on branches where we are working on new features. It’ll run any time code is pushed to the repo and will only run unit tests, though it will also appear later on in the pull request when you attempt to merge the branch. You can use an Action like this in several ways. A developer can use it to ensure everything is as expected before making a PR request. If the PR unit tests fail, you can also see that it wasn’t the feature branch, but the merged code that caused a failure. Alternatively, perhaps your full set of unit tests take 10+ minutes to run and disrupt your developers ability to work in the meantime. By having simplified local tests with more extensive GitHub Actions unit tests, you can free up your developer to work on something else while the tests run in the cloud.
The second action will run when a pull request is created and will again run unit tests. This is similar to the previous action with the important difference that the code being tested will be the merged result of the two branches. This is an important step if the incoming branch is missing changes from the base branch. As an alternative to this, you can use branch protection and set the “Require branches to be up to date before merging” option. Just make sure you select a status check or the option will be ignored.
The third action will run after code is pushed to our primary branch and will deploy our code to a storage location. This will effectively run whenever a pull request has been merged, but will also run any time changes are pushed to the branch. The result is that whatever state our primary branch is in, it will also be the state of our deployed code.