GitHub Actions, simply put is a way to add a bit of automation onto your repository. Every time there is triggering event things happen. Things like running tests, deployment, or even a notification into a slack channel. For our purposes every time there is a push, or a pull-request to the develop or master branches; the code should be built and the automated tests should be run.
It turns out that this is a lot easier than you might think, because, GitHub will create a base workflow for those specific steps and all we need to do is make a few modifications. Easy Peasy.
To get started, click on the Actions, find the appropriate starter workflow, in our case .NET, Then Set up this Workflow. GitHub then populates a web editor to edit the file .github/workflows/dotnet.yml
name: .NET
on:
push:
branches: [ develop ]
pull_request:
branches: [ develop ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Setup .NET
uses: actions/setup-dotnet@v1
with:
dotnet-version: 3.1.301
- name: Restore dependencies
run: dotnet restore
- name: Build
run: dotnet build --no-restore
-name: Test
run: dotnet test --no-build --verbosity normal
.github/workflows/dotnet.yml
This YAML file contains 3 sections: name, on, and jobs. So lets break down what each section does before any changes are made.
name: .NET
Name section of dotnet.yml
The name is the easiest one. It is simply the name of the workflow. It is not required and the default is the path to the file, in this case it should be .github/workflows/dotnet.yml. I haven’t verified that so it might be something a bit different, but you get the idea.
on:
push:
branches: [develop]
pull_request:
branches: [develop]
On section of dotnet.yml
Next is the on section. This is where we define the events that will trigger the workflow. The first triggering event is push and off of that we see branches. Currently just the develop branch is listed. This then repeated for pull_request. So anytime that there is a push or a pull request to the develop branch this workflow will run.
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Setup .NET
uses: actions/setup-dotnet@v1
with:
dotnet-version: 3.1.301
- name: Restore dependencies
run: dotnet restore
- name: Build
run: dotnet build --no-restore
- name: Test
run: dotnet test --no-build --verbosity normal
Jobs section of dotnet.yml
Jobs is where the real meat of this file is. Under jobs there is build. Build is a job and you can use any name here. If you would like to call the job hoobastank, that is perfectly fine. You can have as many jobs here as you want; they will all run in parallel.
A job really is an environment. This is why we have the runs-on. We are specifying that our code is supposed to run on ubuntu. This could also be macos or windows. There are other options we could add to the environment.
This job has 5 steps. They are run in order, and if one fails, they all fail. The first two are predefined actions.
- uses: actions/checkout@v2
checkout step
This first step calls the checkout action, version 2. This checks out the current branch so you can do things to it, like compile. It is something that a great many other developers used, so rather than make everyone type out the same instructions over and over it has already been done for you.
- name: Setup .NET
uses: actions/setup-dotnet@v1
with:
dotnet-version: 3.1.301
checkout step
Much like the previous step, this step uses a predefined action, setup-dotnet. Now there are a two more pieces:name and with. The name is fairly self explanatory, a human readable name for the step. With is a bit more interesting. It is used to pass variables to the action. Here we are specifying the dotnet-version to be 3.1.301.
- name: Restore dependencies
run: dotnet restore
- name: Build
run: dotnet build --no-restore
- name: Test
run: dotnet test --no-build --verbosity normal
build steps
These last three steps are simply running commands to Restore dependencies, Build, and Test on the environment.
That is the breakdown of the auto script. To adjust it so it runs on both the develop and master branches we simply need to change the two branches under on to read [ master, develop ] or [ develop ].
This has been a really longwinded way of saying change two lines very slightly. There is a great deal more that can be done. Here are a few links for your reference.