Release Management with ASP.Net Core and GitHub Actions

In this article, we will learn how to set up automated release creation for an ASP.Net Core project with GitHub Actions

Release management can be a complicated beast at the best of times, and is notoriously hard to get right. Previously, shell scripts and batch files used to be the most common tools used for automation, and countless hours were spent trying to get them working as expected.

This has changed in recent times, with platforms such as GitHub Actions providing a much simpler way of automating tasks and managing releases.

, we have seen how GitHub Actions can be used to set up a pipeline for Continuous Integration (CI). In the following sections, we will build on that, and add a workflow that publishes release artifacts when new code is merged to the 

For the purposes of this tutorial, we will use a simple .NET Core console application. This can be created via the following command using the .NET CLI which is installed along with the SDK.

We will use the GitHub repository that we created in the previous article, which already contains a GitHub Actions CI workflow that builds and runs unit tests on pushes to 

Step 2: Understanding GitHub Tags and Releases 🧐

 is a label that can be applied to any commit in your repository for later identification. Tags are typically used to mark commits for releases.

You can create a tag using the following commands in your terminal/command line.

Tag names can be any arbitrary string, but are usually version numbers like v1.0.0 or v.1.1.2-beta5.

When a tag has been published, it will appear in the 'Tags' section in your repository.

You can then use the created tag to create a GitHub 

 - each release has a title, short description and attachments such as release notes, source code and built artifacts. 

In the next step, we will learn how to build our project and associate the built app code artifacts with the just-created release.

 event to trigger our workflow. This means our workflow will get triggered when a new release is published using the mechanism from the previous step.

name: Publish

on:
  release:
    types: [published]
env:
  DOTNET_VERSION: '6.0.x'
jobs:
  release:
    name: Release
    strategy:
      matrix:
        kind: ['linux', 'windows']
        include:
          - kind: linux
            os: ubuntu-latest
            target: linux-x64
          - kind: windows
            os: windows-latest
            target: win-x64
    runs-on: ${{ matrix.os }}
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Setup dotnet
        uses: actions/setup-dotnet@v3
        with:
          dotnet-version: ${{ env.DOTNET_VERSION }}

      - name: Build
        shell: bash
        run: |
          tag=$(git describe --tags --abbrev=0)
          release_name="app-$tag-${{ matrix.target }}"

          # Build everything
          dotnet publish --framework net6.0 --runtime "${{ matrix.target }}" -c Release -o "$release_name"

          # Pack files
          if [ "${{ matrix.target }}" == "win-x64" ]; then
            # Pack to zip for Windows
            7z a -tzip "${release_name}.zip" "./${release_name}/*"
          else
          tar czvf "${release_name}.tar.gz" "$release_name"
          fi

          # Delete output directory
          rm -r "$release_name"

      - name: Publish
        uses: softprops/action-gh-release@v1
        with:
          files: "app*"
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Let us now understand what this workflow does:

We can now create a release using the steps described earlier.

Let us first tag the last commit in our repo. I'll call the tag 

The tag will now appear in the 'Tags' section, and we can create a release from it. The release notes can be automatically populated based on the commits since the last tag.

Once we hit publish, a release gets created on the 'Releases' page. Note that this only has the source code, and not the built artifacts from the tagged commit.

Publishing the release also triggers our new workflow.

When the workflow has finished, the built ZIP file and tarball are added to the release assets, and we have successfully released v1.0 of our app! 🎉

In this tutorial, we have learnt how to create and automate tasks around releases for an ASP.Net Core project using GitHub Actions. We built on concepts we learnt in the previous tutorial on 

If you find yourself stuck at any point during the tutorial, you can view all the source code on my GitHub 

More detail on all the events that can be used to trigger GitHub Actions workflows can be found in the 

AUTHOR

Krishna Acondy

Continuous Integration (CI) with ASP.Net Core and GitHub Actions

In this article, we will learn how to set up a simple build workflow for an ASP.Net Core project with GitHub Actions.

Modern apps often have large codebases with multiple teams of developers working across different geographical locations and time zones. In this scenario, it is of utmost importance to ensure that each change to the codebase works correctly not just in isolation, but in the context of all the existing code. This keeps quality levels high and guarantees the best possible experience for the app's users. 

Continuous Integration (CI) can be used to automatically run an array of checks on the codebase that could be triggered before code changes are merged, thus ensuring the quality of all released code.

 is a powerful continuous integration (CI) and continuous delivery (CD) platform available for all code repositories hosted on GitHub. It allows you to build, test, and deploy your code on multiple platforms, right from your source code repository.

GitHub Actions are triggered via GitHub workflows, which are 

directory in your repository. A workflow references one or more GitHub Actions, run in a specified sequence to accomplish a given task.

In the following sections, we will learn more about how GitHub Actions and workflows function, and understand how they can be used to automatically build, test, and release an ASP.Net Core project.

For the purposes of this tutorial, let us use a simple .NET Core console application. We can create one using the .NET CLI which is installed along with the SDK.

You can create a repository on GitHub and push the code created by the above command using the instructions in the 

 file can be added to ignore the build output and an optional readme file for documentation.

At this stage, your GitHub repo should look somewhat like this:

Step 2: Designing a CI workflow 🧑‍🎨 

Now that we have our app code on GitHub, we can start creating our automated workflows. We can begin by defining a Continuous Integration(CI) workflow that will run each time code is committed to a PR branch or to 

Let us define a simple CI workflow with three steps that will install our project's NuGet dependencies, build it and run any tests, all using the 

 CLI. We want this workflow to run on each commit to a PR branch or to 

, and run on two platforms - Linux and Windows, to make sure our app works perfectly on both.

As can be seen from the diagram above, each step in the workflow depends on the step before it, and can only run if the previous step is completed successfully.

 file in there that defines this as a GitHub workflow.

The YAML syntax is quite simple and readable and is easy to understand. Please refer to the comments inline in the below code block for more context.

name: CI

on:
  push:
  pull_request:
    branches: [ main ]
# Specifies the dotnet SDK version for one of the
# below steps
env:
  DOTNET_VERSION: '6.0.x'
# This section contains all the jobs to be run.
jobs:
  ci:
    name: ci-${{matrix.os}}
    # Specifies what platforms the workflow should
    # run on.
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest]
    steps:
    # Checks out the source code at the latest commit
    - uses: actions/checkout@v3
    # Installs the .NET SDK on the build machine
    - name: Setup .NET
      uses: actions/setup-dotnet@v3
      with:
        dotnet-version: ${{ env.DOTNET_VERSION }}
    # Installs any NuGet packages required.
    - name: Install dependencies
      run: dotnet restore
    # Builds the project
    - name: Build
      run: dotnet build --configuration Release --no-restore
    # Runs any tests in the project
    - name: Test
      run: dotnet test --no-restore --verbosity normal

Let us now look at the structure of the workflow in detail:

 predefined actions in our workflow. These, along with a wide variety of other actions are available in the 

. If one isn't available for your specific purpose, you can 

 using either JavaScript or a Docker container.

One of the great things about GitHub Actions is that the workflows are defined right alongside your source code. This means you can create, test, and refine new workflows on a branch before applying them to your 

 , commit the workflow file that we have defined above in 

, and open a pull request to trigger the workflow.

GitHub immediately recognizes the new workflow and starts the process of running the jobs defined in it. You should see status updates for each of the jobs appearing at the bottom of the pull request.

You can then click through to view the details of each workflow run, where you can read through the console output from the various commands running on the build machine.

This can also be accessed from the 'Actions' tab on your repository page.

Once all checks have been completed, the branch can be merged into 

. This will trigger a run of our workflow jobs against the newly merged code in 

A very important part of your CI setup is the idea of ensuring that only good code makes it to the 

 branch. To this end, GitHub allows you to set up rules that require certain GitHub Actions workflows have successfully completed before a branch can be merged. This can be used in conjunction with code reviews to keep quality levels high.

The rule in the screenshot below specifies that pull requests are required for merges to 

You can add a status badge for any GitHub Actions workflow in your repository to your readme file, which shows visitors and potential users of your repo the status of your CI/CD pipelines.

This can be added using the URL scheme below and added as a markdown image URL in your readme:

https://github.com/<OWNER>/<REPOSITORY>/actions/workflows/<WORKFLOW_FILE>/badge.svg

There are more parameters you can add to the URL, that are documented 

In this article, we have learned how to set up a continuous integration workflow for an ASP.NET Core app using GitHub Actions.

We have also discovered how to leverage GitHub's branch protection rules with workflows to ensure only high-quality code makes it to the 

Most of the concepts we have explored around creating and running workflows are generic in nature, so you can apply them to any project with a different technology stack with the appropriate modifications.

In an upcoming article, we will take things a step further and learn how to create releases and publish artifacts for ASP.Net Core projects with GitHub Actions workflows.

All the example code used in this article is available on 

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

The Future Of Software Engineering

Tutorials on Continuous Integration (ci)

Release Management with ASP.Net Core and GitHub Actions

Continuous Integration (CI) with ASP.Net Core and GitHub Actions

This has been a really good investment!

Advance your career with newline Pro.

Email Newsletter

Popular Topics

Masterclasses

Tutorials

Fullstack React with TypeScript