Moving from Azure Pipelines to Github Actions

Github Actions has the same basic structure as Azure Pipelines and shares a lot of other similarities with each other. Usually you find the differences when it comes to syntax and the so called Actions which are equal to built-in tasks in Azure Pipelines.

To get started with Github Actions you need a .github/workflows directory in your repository on Github and inside the folder workflows you can add a .yml file which will be your Github Actions file. A shortcut to create it is to click on the Actions bar in your Github repository and set up a workflow yourself :

To decide when Github Actions will trigger a workflow you need to define it by using on (same as trigger on Azure Pipelines), for example here where it is triggered when making a push or pull request to the master branch:

on:
  push:
    branches: main
  pull_request:
    branches: main

Jobs & Steps

Inside jobs (same as stages on Pipelines) you define what you want Github Actions to do. First you name the job and then decide which type of machine to use by using runs-on.

Inside steps you define all the tasks that you want to be executed as parts of the job. For example here can we see a job called build which runs on a linux machine. First it uses the action actions/checkout@v2 so your workflow can access the repository. Then with actions/setup-dotnet@v1 it sets up a.NET CLI environment. After that we are able to write dotnet commands by using run:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Setup .NET
      uses: actions/setup-dotnet@v1
      with: |
        dotnet-version: 5.0.x
    - name: Restore dependencies
      run: dotnet restore
    - name: Build
      run: dotnet build --no-restore
    - name: Test
      run: dotnet test --no-build --verbosity normal

Variables & Environment Variables

Variables in Github Actions are defined by using env (Environment variable). Github Actions also contains predefined variables the same way as Azure Pipelines does but with different names. When using variables the praxis is to use dollarsign with double curly brackets, for example if you want to print the variable _firstname:

run: echo ${{ env.first_name }}
env:
  first_name: John

Secret Files

Working with secure files is not as simple on Github Actions compared to Azure Pipelines. A workaround is to convert your file to a base 64 string and save that value on your repositorys Secrets. You can find it by clicking Settings in your repository and choosing Secrets and Actions where you are able to name it and add the value.

Inspired by this blogspot, we are able to store the secret value in a variable by writing secrets. and the name of the secret, for example ${{ secrets.SECRET_VALUE }}. In this example we recreate the file from a base 64 string and save it to a temporary directory and therefore we are able to use it.

 - name: Create file secretFile.pfx
        run: |
          $secretFile = Join-Path -Path $env:RUNNER_TEMP -ChildPath "secretFile.pfx";
          $encodedBytes = [System.Convert]::FromBase64String($env:fileb64);
          Set-Content $secretFile -Value $encodedBytes -AsByteStream;
        shell: pwsh
        env:
          fileb64: ${{ secrets.SECRETFILE_FILEB64 }}

The obvious advantage of using Github Actions is that you do not need tools outside of Github in order to automate your workflow. Just click on Actions in your repository, choose an already existing workflow or create your own and you are own your way!

Author: Jonas Rönnqvist is a .NET student currently doing his internship at Active Solution working with Active Login.