In this article, we gonna cover the CI/CD process of a .NET Framework project using GitHub Actions to build, test, and run.
What are GitHub Actions?
GitHub Actions provide a flexible way to automate various tasks, such as building, testing, and deploying applications, directly from your GitHub repositories. These actions are defined in YAML files called workflows, which can be customized to suit your project’s specific requirements.
For reference, I have set up a repository in GitHub with a PoC (Proof of Concept) that is based on this tutorial, this repository has a lot more features than the simple ones that I will guide you through this tutorial.
Creating a GitHub Actions Pipeline for .NET Framework Projects:
1. Open your repository on GitHub and click on the “Actions” tab.
2. GitHub provides numerous workflow templates for different programming languages and frameworks. For this particular situation, let’s just click on Set up a workflow yourself link above the Choose a workflow section.
3. In the GitHub Actions editor, let’s give a name for this workflow and set up the triggers that will fire this workflow run.
name: Build .NET Framework on: push: workflow_dispatch:
In the first line we defined the workflow name to: Build .NET Framework
In the next lines were defined the workflow triggers: push events and workflow_dispatch.
The push event will trigger this workflow every time a new push is done to this repository
The workflow_dispatch allows us to run the workflow manually from the Actions page.
You can find a complete reference of all events that trigger a workflow run here: Events that trigger workflows
4. Now we need to define our job to build the solution. But for it, we need some steps like:
- Inform GitHub Actions runner to run this workflow in a Windows-based environment
- Checkout the code
- Setup MSBuild as the build tool
- Setup NuGet tool to restore packages
- Setup VSTest as the test tool
- Restore the NuGet packages
- Build the solution
- Run the test project
- (Optionally) Run the fresh build executable (assuming that is a .exe project)
So let’s do that, let’s first create a job and set Windows-based environment:
jobs: build: name: Build runs-on: windows-latest
In these four lines, we did:
- Informed GH Actiosn that we will start out the jobs section
- Create our first job named build (it could be anything)
- Give a name to the job (for logging purposes)
- Selected which environment we want to run this job (environments are job-based, so different jobs can run in different environments)
Now we need to configure the job`s steps as we mentioned before
steps: - name: Checkout Code uses: actions/checkout@v3 with: fetch-depth: 0 - name: Setup MSBuild Path uses: email@example.com env: ACTIONS_ALLOW_UNSECURE_COMMANDS: true - name: Setup VSTest uses: darenm/Setup-VSTest@v1.2 - name: Setup Nuget uses: NuGetfirstname.lastname@example.org env: ACTIONS_ALLOW_UNSECURE_COMMANDS: true - name: Restore NuGet Packages run: nuget restore your-solution-name.sln - name: Build Release run: msbuild your-solution-name.sln /p:Configuration=Release - name: Test run: vstest.console.exe path-to-test-binary.dll - name: Run run: path-to-application-binary.exe
In the below code, we have 8 steps that will do all the required actions to set up the environment, restore NuGet packages, build, test and finally run the application.
- Replace your-solution-name.sln with the path/name of your solution in both steps: Restore NuGet Packages and Build Release.
- In the Test step, replace path-to-test-binary.dll with the path where the tests project dll is present after a successfully build release run. Usually, this is inside the bin/Release/ directory with the tests project directory.
- In the path-to-application-binary.exe replace with the /bin/Release/ directory and file name of the main project of your solution.
5. Save and Trigger the Workflow: Once you’ve customized the workflow according to your project’s requirements, save the changes and trigger the workflow manually or automatically on specific events, such as pushes to the repository or pull requests.
6. Monitor the Pipeline: GitHub Actions provides a comprehensive view of the pipeline execution. You can track the progress, view logs, and debug any potential issues directly from the Actions tab in your repository.
Here we have the full workflow file to build, test and run a .NET Framework solution within GitHub Actions:
name: Build .NET Framework on: push: workflow_dispatch: jobs: build: name: Build runs-on: windows-latest steps: - name: Checkout Code uses: actions/checkout@v3 with: fetch-depth: 0 - name: Setup MSBuild Path uses: email@example.com env: ACTIONS_ALLOW_UNSECURE_COMMANDS: true - name: Setup VSTest uses: darenm/Setup-VSTest@v1.2 - name: Setup Nuget uses: NuGetfirstname.lastname@example.org env: ACTIONS_ALLOW_UNSECURE_COMMANDS: true - name: Restore NuGet Packages run: nuget restore your-solution-name.sln - name: Build Release run: msbuild your-solution-name.sln /p:Configuration=Release - name: Test run: vstest.console.exe path-to-test-binary.dll - name: Run run: path-to-application-binary.exe
Benefits of GitHub Actions for your projects:
By leveraging GitHub Actions to create a pipeline for your projects, developers can enjoy several benefits, including:
1. Automated Builds: GitHub Actions enables automatic build execution whenever changes are pushed to the repository, ensuring consistent and up-to-date builds.
2. Testing Automation: Integrate automated testing into your pipeline using tools like xUnit or NUnit. This ensures that code changes are thoroughly tested before deployment, reducing the risk of introducing bugs into production.
3. Submit coverage reports to Sonar Cloud, Code Climate, Codefactor, Codecov, etc
4. Deployment Flexibility: GitHub Actions provides a range of deployment options, allowing you to seamlessly deploy your .NET Framework projects to various hosting environments, such as Azure, AWS, or on-premises servers.
5. Collaboration and Transparency: With GitHub Actions, all pipeline workflows are visible to the entire development team, promoting collaboration and transparency. Team members can review, provide feedback, and contribute to the pipeline configuration.