Building with GitHub Actions

Adding a GitHub Action to a repository is pretty easy. You can use the Web UI and click on the Actions menu and select one of the builtin workflows. If you’ve use Azure Pipelines before, then things will feel kind of similar. Both use YAML as the format for describing build workflows, though there are subtle differences.

Using the Web UI is a good way to get started, plus you can use the search field to look for suitable actions. It is just a file though, so you can edit it and commit it just like any other file.

Each workflow is stored in a separate file. These files reside in the special .github/workflows directory.

Here’s a simple workflow:

name: CI

on:
  push:
    branches: [ master ]

jobs:
  build:
    runs-on: windows-latest
    steps:
    - uses: actions/checkout@v2
      with:
        fetch-depth: 0

    - name: nuget restore
      run: nuget restore -Verbosity quiet

    - name: setup-msbuild
      uses: microsoft/setup-msbuild@v1

    - name: Build
      id: build
      run: |
        msbuild /p:configuration=Release /p:DeployExtension=false /p:ZipPackageCompressionLevel=normal /v:m

The on is the trigger which will cause this workflow to run. Common triggers include push or pull_request, and you can filter triggers to only fire on specific branches. The full list of available triggers are listed in Webhook events.

Under jobs, you can list one or more jobs. Each job can run on a runner (build agent). Runners can be ones provided by GitHub or yourself. The GitHub hosted runners actually have the same installed software as the Azure Pipelines hosted agents.

A job (eg. build in the example above) also lists actions under the steps section. There’s a number of actions provided by GitHub and lots of 3rd party actions too. It’s pretty easy to create a new action. In a future post I’ll give an overview of the custom action I created.

The above workflow does a git checkout (with full history), then restores NuGet packages, ensures msbuild is available and then runs msbuild.

Once your workflow file is committed to the repository, you can view the execution history, or edit the workflow through the Actions tab.