Understand how GitHub Actions can enhance your .NET programming workflow and workplace efficiency in this article. I’ll teach you about using workflow composition to automate common .NET app development situations.

An overview of GitHub Actions

By the support of GitHub Actions, programmers who use GitHub to manage their repositories have robust integration (CI) and continuous deployment (CD) functionality. When programmers submit modifications to a GitHub repository’s primary subsidiary (usually main), this is a typical developer dilemma. While these modifications are frequently reviewed by users, robotic tests can be used to guarantee that the code builds and the tests execute. 

GitHub Actions enable you to create, debug, and publish your code directly from your https://github.com codebase. Workflows on GitHub absorb GitHub Actions. Within your Git repository, a YAML (either *.yml or *.yaml) file is called a GitHub workflow. These process files are located at the root of the repository’s.github/workflows/ directory. A workflow is a set of instructions that includes one or more GitHub Actions, each of which performs a specified action.

The GitHub Actions jargon

Let’s specify a few of these concepts so that we don’t use them incorrectly:

• GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform for automating your build, test, and deployment process.
• A workflow is a programmable automated procedure that performs one or more tasks.
• A workflow run is triggered by an event, which is a specific activity in a repository.
• A job is a series of workflow stages that all run on the same runner.
• An action is a GitHub Actions platform custom application that performs a sophisticated but regularly repeated activity.
• runner: When your workflows are triggered, a runner is a server that executes them.

The workflow code on GitHub

Workflow requirements are outlined in the order in which tasks should be completed and the actions that should be followed. Each process has a title and a collection of prompts, or actions, that must be addressed. Unless your process is repeatable, you must define at least one trigger for it to execute. When modifications are published or a merge application is sent to the standard line, a common .NET GitHub workflow is to build and test your C# code. Take a look at the following procedural file: 

name: build and test
on:
push:
pull_request:
branches: [ main ] paths-ignore:
– ‘README.md’
env:
DOTNET_VERSION: ‘6.0.x’
jobs:
build-and-test:
name: build-and-test-${{matrix.os}}
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [ubuntu-latest, windows-latest, macOS-latest] steps:
– uses: actions/checkout@v2
– name: Setup .NET
uses: actions/setup-dotnet@v1
with:
dotnet-version: ${{ env.DOTNET_VERSION }}
– name: Install dependencies
run: dotnet restore
– name: Build
run: dotnet build –configuration Release —no-restore
– name: Test
run: dotnet test —no-restore –verbosity normal

I’m not presuming you know everything there is to know about this process, and even though it’s only thirty lines long, there’s still a lot to unpack. I created a Mermaid-powered flow chart to explain how a programmer may perceive this procedure.

Here’s the identical workflow document, but with explicit remarks to add background (if you’re familiar with the workflow terminology, you can skip to another stage).

# The name of the workflow.
# This is the name that’s displayed for status
# badges (commonly embedded in README.md files).
name: build and test
# Trigger this workflow on a push, or pull request to
# the main branch, when either C# or project files changed
on:
push:
pull_request:
branches: [ main ] paths-ignore:
– ‘README.md’
# Create an environment variable named DOTNET_VERSION
# and set it as “6.0.x”
env:
  DOTNET_VERSION: ‘6.0.x’ # The .NET SDK version to use
# Defines a single job named “build-and-test”
jobs:
build-and-test
# When the workflow runs, this is the name that is logged
# This job will run three times, once for each “os” defined
name: build-and-test-${{matrix.os}}
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [ubuntu-latest, windows-latest, macOS-latest] # Each job run contains these five steps
steps:
# 1) Check out the source code so that the workflow can access it.
– uses: actions/checkout@v2
# 2) Set up the .NET CLI environment for the workflow to use.
#    The .NET version is specified by the environment variable.
– name: Setup .NET
uses: actions/setup-dotnet@v1
with:
dotnet-version: ${{ env.DOTNET_VERSION }}
# 3) Restore the dependencies and tools of a project or solution.
– name: Install dependencies
run: dotnet restore
 # 4) Build a project or solution and all of its dependencies.
 – name: Build
run: dotnet build –configuration Release —no-restore
# 5) Test a project or solution.
– name: Test
run: dotnet test —no-restore –verbosity normal

The following workflow file has multiple comments that assist in understanding each step of the process. You’ll see that the instructions cover a variety of GitHub Actions and basic run instructions. The connection here between devouring GitHub workflow and a GitHub Action is that workflows consume actions. The consumption workflow determines how effective a GitHub Action is. Workflows can be used to specify anything from simple chores to complex creations, and almost anything within. See the .NET docs pages below for more information on how to create GitHub processes for .NET apps:

• Create a build validation GitHub workflow | Microsoft Docs
• Create a test validation GitHub workflow | Microsoft Docs
• Create a publish app GitHub workflow | Microsoft Docs
• Create a security scan GitHub workflow | Microsoft Docs

Checking the progress of GitHub

One of the most important advantages of workflows is that they allow you to design conditional status checks that can algorithmically reject a deployment. A workflow could be set up to verify the state of a pull request (PR), and if the workflow rejects — for example, because the PR’s source code doesn’t generate — the PR can be denied from merging. Take a look at the image below, which indicates that two tests ended in failure, preventing the PR from being integrated.

As the programmer is responsible for evaluating a PR, you’d notice that the pull request has failed state tests right away. To have all of the status tests to clear, you’d collaborate with the developer who submitted the PR. A “green build,” or one that has passed all of its status inspections, is depicted in the image below.

.NET developers should be familiar with the following GitHub actions

You’re probably acquainted with the .NET CLI if you’re a .NET developer. With the .NET SDK, you get the .NET CLI. You can get the .NET 6 SDK if you don’t currently have the .NET SDK. 

There are 5 phases, each of which contains the run or uses syntax, using the prior workflow file as a guide:

Several stages employ GitHub Actions, which are referenced using the user’s terminology, while others execute instructions. Check Workflow syntax for GitHub Actions: uses and runs for extra info on the distinctions.

NuGet bundles are used by .NET apps. Various dependencies that change infrequently, such as NuGet packages, might be cached to improve workflows. You may use actions/cache to cache NuGet packages, for example:

steps:
– uses: actions/checkout@v2
– name: Setup dotnet
uses: actions/setup-dotnet@v1
with:
dotnet-version: ‘6.0.x’
– uses: actions/cache@v2
with:
path: ~/.nuget/packages
# Look to see if there is a cache hit for the corresponding requirements file
key: ${{ runner.os }}-nuget-${{ hashFiles(‘**/packages.lock.json’) }}
restore-keys: |
${{ runner.os }}-nuget
– name: Install dependencies
run: dotnet add package Newtonsoft.Json –version 12.0.1

See GitHub Docs: Building and Testing .NET – Cache Requirements for further details.

You might be curious to learn about some extra GitHub Actions in contrast to using the normal GitHub Actions or citing CLI commands using the launch syntax.

GitHub actions not listed above

Several .NET frameworks are available. The dot net GitHub organisation hosts GitHub Actions:

The .NET developers are creating GitHub Actions which you might find valuable in your company. Check out zyborg/dotnet-tests-report, a GitHub Action that allows you to run .NET testing and produce results and labels. Give their repo a star if you use this GitHub Action.

A few words about .NET workloads

.NET operates on every platform and may be used to create everything. When constructing from a GitHub workflow, there are a few additional tasks that may have to be added. There are numerous tasks accessible; for instance, consider the result of the dot net workflow searching orders: 

dotnet workload search

Workload ID         Description

—————————————————————————————–

android             .NET SDK Workload for building Android applications.

android-aot      .NET SDK Workload for building Android applications with AOT support.

ios                      .NET SDK Workload for building iOS applications.

mac catalyst     .NET SDK Workload for building macOS applications with MacCatalyst.

macos                .NET SDK Workload for building macOS applications.

maui                  .NET MAUI SDK for all platforms

maui-android  .NET MAUI SDK for Android

maui-desktop  .NET MAUI SDK for Desktop

maui-ios           .NET MAUI SDK for iOS

maui-macc catalyst    .NET MAUI SDK for Mac Catalyst

maui-mobile    .NET MAUI SDK for Mobile

maui-windows    .NET MAUI SDK for Windows

tvos                   .NET SDK Workload for building tvOS applications.

wasm-tools     .NET WebAssembly build tools

Synopsis

I discussed the key differences between GitHub Actions and GitHub workflows in this post. In an example workflow file, I described and inspected each line. Then I showed you how a developer could use a sequence diagram to monitor the execution of a GitHub workflow. I mentioned a few extra resources that you may not be aware of. See .NET Docs: GitHub Actions and.NET for further details.