In this overview, you'll learn what roleGitHub Actions play in .NET application development. GitHub Actions allow your source code repositories to automate continuous integration (CI) and continuous delivery (CD). Beyond that, GitHub Actions expose more advanced scenarios—providing hooks for automation with code reviews, branch management, and issue triaging. With your .NET source code in GitHub you can leverage GitHub Actions in many ways.

GitHub Actions

GitHub Actions represent standalone commands, such as:

• actions/checkout - This action checks-out your repository under$GITHUB_WORKSPACE, so your workflow can access it.
• actions/setup-dotnet - This action sets up a .NET CLI environment for use in actions.
• dotnet/versionsweeper - This action sweeps .NET repos for out-of-support target versions of .NET.

While these commands are isolated to a single action, they're powerful throughworkflow composition. In workflow composition, you define theevents that trigger the workflow. Once a workflow is running, there are variousjobs it's instructed to perform. Each job defines any number ofsteps. Thesteps delegate out to GitHub Actions, or alternatively call command-line scripts.

For more information, seeIntroduction to GitHub Actions. Think of a workflow file as a composition that represents the various steps to build, test, and/or publish an application. Many.NET CLI commands are available, most of which could be used in the context of a GitHub Action.

Custom GitHub Actions

While there are plenty of GitHub Actions available in theMarketplace, you may want to author your own. You can create GitHub Actions that run .NET applications. For more information, seeTutorial: Create a GitHub Action with .NET.

Workflow file

GitHub Actions are utilized through a workflow file. The workflow file must be located in the.github/workflows directory of the repository, and is expected to be YAML (either*.yml or*.yaml). Workflow files define theworkflow composition. A workflow is a configurable automated process made up of one or more jobs. For more information, seeWorkflow syntax for GitHub Actions.

Example workflow files

There are many examples of .NET workflow files provided astutorials andquickstarts. Here are several good examples of workflow file names:

Encrypted secrets

To useencrypted secrets in your workflow files, you reference the secrets using theworkflow expression syntax from thesecrets context object.

${{ secrets.MY_SECRET_VALUE }} # The MY_SECRET_VALUE must exist in the repository as a secret

Secret values are never printed in the logs. Instead, their names are printed with an asterisk representing their values. For example, as each step runs within a job, all of the values it uses are output to the action log. Secret values render similar to the following:

MY_SECRET_VALUE: ***

${{ secrets.GITHUB_TOKEN }}

For more information, seeUsing encrypted secrets in a workflow.

Events

Workflows are triggered by many different types of events. In addition to Webhook events, which are the most common, there are also scheduled events and manual events.

Example webhook event

The following example shows how to specify a webhook event trigger for a workflow:

name: code coverageon:  push:    branches:      - main  pull_request:    branches:      - main, stagingjobs:  coverage:    runs-on: ubuntu-latest    # steps omitted for brevity

In the preceding workflow, thepush andpull_request events will trigger the workflow to run.

Example scheduled event

The following example shows how to specify a scheduled (cron job) event trigger for a workflow:

name: scanon:  schedule:  - cron: '0 0 1 * *'  # additional events omitted for brevityjobs:  build:    runs-on: ubuntu-latest    # steps omitted for brevity

In the preceding workflow, theschedule event specifies thecron of'0 0 1 * *' which will trigger the workflow to run on the first day of every month. Running workflows on a schedule is great for workflows that take a long time to run, or perform actions that require less frequent attention.

Example manual event

The following example shows how to specify a manual event trigger for a workflow:

name: buildon:  workflow_dispatch:    inputs:      reason:        description: 'The reason for running the workflow'        required: true        default: 'Manual run'  # additional events omitted for brevityjobs:  build:    runs-on: ubuntu-latest    steps:      - name: 'Print manual run reason'        if: ${{ github.event_name == 'workflow_dispatch' }}        run: |          echo 'Reason: ${{ github.event.inputs.reason }}'    # additional steps omitted for brevity

In the preceding workflow, theworkflow_dispatch event requires areason as input. GitHub sees this and its UI dynamically changes to prompt the user into provided the reason for manually running the workflow. Thesteps will print the provided reason from the user.

For more information, seeEvents that trigger workflows.

.NET CLI

The .NET command-line interface (CLI) is a cross-platform toolchain for developing, building, running, and publishing .NET applications. The .NET CLI is used torun as part of individualsteps within a workflow file. Common command include:

• dotnet workload install
• dotnet restore
• dotnet build
• dotnet test
• dotnet publish

For more information, see.NET CLI overview.

See also

For a more in-depth look at GitHub Actions with .NET, consider the following resources:

• Quickstart(s):

  • Quickstart: Create a build validation GitHub Action
  • Quickstart: Create a test validation GitHub Action
  • Quickstart: Create a publish app GitHub Action
  • Quickstart: Create a security scan GitHub Action

• Tutorial(s):

  • Tutorial: Create a GitHub Action with .NET