This article will explain GitHub Actions alongside a practical example of running one GitHub Actions for Continuous Integration of a .NET 6 Web App.
The manual process of packaging and deploying your software is painful, takes a lot of time, and leads to errors. Usually, this manual process is described in a manual and executed by a human, and if any step is skipped or misunderstood then your deployed will probably face misbehavior in your software.
Using GitHub Actions can save precious time and energy for your team to have your software packed, tested, and deployed.
What is a GitHub Actions?
GitHub Actions is a powerful tool for CI and CD to automate your Software Development pipelines. With GitHub actions, you can automate your build, test, and deployment process without requiring manual intervention.
You can use GitHub Actions to track a repository branch and run a workflow every time its trigger is activated, or you can also start its workflow manually.
WorkFlows
A workflow is the macro piece of the automation process, it is in the workflow that we define the steps to be executed to automate the CI and, or, CD process.
The workflow is defined in a YAML file and split into 1-N jobs in the repositories, and a repository can have 0-N workflows. One workflow can be used as a step from another workflow and its execution can be triggered by a specified event, a specified schedule, or manually.
Events
Events are responsible to trigger a workflow in a repository, those events are going to be listening to the changes made into your repository and start the workflow as soon as one event is flagged as the workflow trigger.
Examples of events are: issue opened, pull request completed, commit pushed, POST to a Web API, etc.. You can find a list of all the events from the link below:
Jobs
A job is a set of ordered steps to be executed sequentially, or in parallel, by a runner, or a virtual machine. Those steps can be to execute a script defined by you or execute a pre-defined action.
If a job is executed sequentially it is because it depends on the successful execution of a previous job, otherwise, the jobs are running in parallel. By default, the jobs do not have any dependency and run in parallelism.
Actions
The actions are pre-defined tasks and are available to be used in your Workflows from GitHub Marketplace. With these actions, you can save time to perform a complex and repetitive task by reusing the same template used by many others projects and people.
If you do not find the action that best suits your needs, then you can write your own task and make it available to others through the GitHub Marketplace.
Runners
Runners are the platform that will be running your workflows, having the capacity to run a job at a time. If we compare it to Azure DevOps we have the Agents doing the same work as the GitHub Runners.
GitHub offers free runners on Ubuntu Linux, macO, and Microsoft Windows. If needed, you can host your own self-hosted runner with its specificities like operational system and hardware configuration.
Benefits of using GitHub Actions
There are enormous benefits to using GitHub Actions. besides making use of the community to help you and give advice to solve your specific issues, you can also use the Actions available on GitHub Marketplace which will be enough for most cases.
But certainly, the main benefit is to have your workflows automated without the risk of a human failure to affect the software. The GitHub Actions workflows are supposed to be executed as many times as needed and always with the same behavior.
Workflow File - YAML Syntax
The followings are the main YAML commands that you can make usage when building your GitHub Action Workflow:
- Name. The workflow name or the task name. It is optional.
- Run-Name. The workflow or task name is based on a command to create a dynamic name. It is optional.
- On. Specifies the trigger that will start the workflow. It is mandatory.
- Jobs. Groups the jobs that will run in the workflow. It is mandatory.
- Runs-on. Assigning a runner for the job. It is mandatory.
- Steps. Groups the actions of the job. It is mandatory.
- Uses. Used to define the actions.
- With. Used alongside the command above to define one specific action.
- Run. Used to execute commands in the runner.
GitHub Actions Implementation Step by Step
The .Net 6 Web APP
You can clone the Web API used in this article In the following repository:
GitHub Action - Continuous Integration
In this example, we are implementing a Continuous Integration workflow using GitHub Actions.
Select the .NET built-in workflow
![GitHub Actions with dotNET 6 Web APP]()
This will be generated .yml file,
# This workflow will build a .NET project
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-net
name: .NET
on:
push:
branches: [ "master" ]
pull_request:
branches: [ "master" ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup .NET
uses: actions/setup-dotnet@v3
with:
dotnet-version: 6.0.x
- name: Restore dependencies
run: dotnet restore
- name: Build
run: dotnet build --no-restore
- name: Test
run: dotnet test --no-build --verbosity normal
Modify the .yml file as follows,
name: .NET
on:
push:
branches: [ "master" ]
pull_request:
branches: [ "master" ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup .NET
uses: actions/setup-dotnet@v3
with:
dotnet-version: 6.0.x
- name: Restore dependencies
run: dotnet restore
working-directory: ./ArchitectureThreeLayersWebAPI
- name: Build
run: dotnet build --no-restore
working-directory: ./ArchitectureThreeLayersWebAPI
- name: Test
run: dotnet test --no-build --verbosity normal
working-directory: ./ArchitectureThreeLayersWebAPI
Result
![GitHub Actions with dotNET 6 Web APP]()
Congratulations! You have successfully created your first Workflow using GitHub Actions.
External References