For the book updates and community contributions

Workflow structure 
Workflows are defined in YAML files, and contain several common nodes: 
•
a name 
•
a trigger, defined by an on section 
•
one or more job sections composed of one or more steps 
•
optional attributes such as environment variables 
Jobs are run on 
runners
. You can use 
hosted runners
, which are spun up by GitHub during the 
workflow and then thrown away. Hosted runners are great because you don’t have to maintain your 
own build infrastructure. For workflows that require a specific build environment, or for running 
workflows on a private network, you can also use 
private
runners. To create a private runner, install the 
runner on any machine that supports .NET. 
Each job will specify what runner GitHub should use to execute the steps. You can also specify 
dependencies between jobs using the needs attribute. Deployment jobs can also specify an 
environment to target. 
The steps node can be as easy as inline commands, or they can be actions. Most CI workflows will 
have a combination of run steps (for executing scripts) and actions. Individual actions are pulled into 
the workflow by referencing the GitHub Action repository (and optionally a tag or commit hash for 
specific versions) and specifying any parameters using the with keyword. 
Tip 
For more information, see 
GitHub Actions YAML syntax
. 
Create a basic build workflow 
A primary principle of effective DevOps is to “build once, and deploy many times”. You’ll start by 
creating a workflow to build a basic .NET app. In the next step, you’ll publish the output to prepare for 
deployment. 
1.
Navigate to your GitHub repository and select the 
Actions
tab. 
2.
GitHub detects that there’s .NET code in the repository and suggests a .NET workflow template. 
Select