GitHub Actions with .NET, Part 3 - Manual Approvals

Full source code available here.

In the previous post, I showed how to make a job dependant on another job, in that example, a release build would only be performed if a debug build succeeded - that was a very contrived scenario, but showed the mechanics of forcing one thing to happen prior to another.

In this post, I’m going to expand on that and add a manual approval step for the release build, requiring a designated person to approve the second job.

GitHub Environments

To add an approver to a job, the repository has to be either public or you (the developer) needs to have an Enterprise account, the Team account is not enough.

In the public repository go to Settings, then Environment, and add a “release” environment.

The Code

I’m using the same C# as in the previous post, very simple.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
class Program
{
    static void Main(string[] args)
    {
        #if DEBUG
            Console.WriteLine("Hello World! From debug build.");
        #endif
        #if RELEASE       
            Console.WriteLine("Hello World! From release build.");
        #endif
    }
}

The Workflow

The workflow remains almost the same as the previous post, with the addition of just two lines, 37 and 38. The environment name must match the one chosen above.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
name: A workflow to build an application in debug and release, with manual approval for the release build

on:
  push:
    branches: [ main ]

jobs:
  debug-build:
    name: Build a debug versions of the app
    runs-on: ubuntu-latest

    steps:
    - name: Checkout source code
      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 -c debug --no-restore
      
    - name: Upload the debug build artifact
      uses: actions/upload-artifact@v2.2.2
      with:
        # Artifact name
        name: HelloWorldDebug #.zip will be added automatically
        path: ./bin/debug/net5.0/*.*

  release-build:
    needs: debug-build
    name: Build a release version of the app
    environment:
      name: release
    runs-on: ubuntu-latest

    steps:
    - name: Checkout source code
      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 -c release --no-restore

    - name: Upload the release build artifact
      uses: actions/upload-artifact@v2.2.2
      with:
        # Artifact name
        name: HelloWorldRelease #.zip will be added automatically
        path: ./bin/release/net5.0/*.*

Running it

When I push to main or make a PR to main the workflow will be kicked off.

Once the first job completes, manual approval will be required before moving on to the second job.

I am the designated user who can approve the next job, so I do.

With the approval in place, the second job runs and completes.

The info about the review is shown, and artifacts are available for download.

Job done! In the next post, I’ll show how to use Pulumi with GitHub Actions to create AWS S3 infrastructure and upload a zip.

Full source code available here.

comments powered by Disqus

Related