Before starting, you need to make sure you have your own GitLab instance or have registered GitLab.com.
Check in your .NET project.
Make sure there is the .sln
file in the root of the repository:
Add the following packages to all your unit test projects:
- coverlet.collector
- JunitXml.TestLogger
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net6.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="coverlet.collector" Version="3.2.0">
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
<PrivateAssets>all</PrivateAssets>
</PackageReference>
<PackageReference Include="JunitXml.TestLogger" Version="3.0.124" />
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.3.2" />
<PackageReference Include="MSTest.TestAdapter" Version="2.2.10" />
<PackageReference Include="MSTest.TestFramework" Version="2.2.10" />
</ItemGroup>
</Project>
Now you can write some unit tests with your C# code.
And create the .gitlab-ci.yml
with content:
(I'm using a Linux agent\runner, with .NET 6 installed.)
stages:
- build
- test
- publish
before_script:
- 'export DOTNET_CLI_TELEMETRY_OPTOUT=1'
- 'export PATH=$PATH:$HOME/.dotnet/tools'
- 'dotnet tool install dotnet-reportgenerator-globaltool --global || echo "DRG already installed."'
build:
stage: build
script:
- dotnet build --no-self-contained
test:
stage: test
needs:
- build
coverage: '/TOTAL_COVERAGE=(\d+.\d+)/'
script:
- dotnet test *.sln --collect:"XPlat Code Coverage" --logger "junit;MethodFormat=Class;FailureBodyFormat=Verbose"
- reportgenerator -reports:"**/coverage.cobertura.xml" -targetdir:"." -reporttypes:"cobertura"
- COVERAGE_VALUE=$(grep -oPm 1 'line-rate="\K([0-9.]+)' "./Cobertura.xml")
- COVERAGE=$(echo "scale=2; $COVERAGE_VALUE * 100" | bc)
- 'echo "TOTAL_COVERAGE=$COVERAGE%"'
artifacts:
when: always
expire_in: 1 day
paths:
- ./**/TestResults.xml
- ./Cobertura.xml
reports:
junit:
- ./**/TestResults.xml
coverage_report:
coverage_format: cobertura
path: ./Cobertura.xml
publish:
stage: publish
needs:
- test
script:
- dotnet publish --configuration Release --runtime linux-x64 --no-self-contained *.sln
pack:
stage: publish
needs:
- test
script:
- dotnet build --configuration Release --no-self-contained *.sln
- dotnet pack --configuration Release *.sln
artifacts:
expire_in: 1 week
paths:
- '**/*.nupkg'
Now you can try to run your pipeline.
And unit test results will be shown here:
And code coverage results will also be shown:
When you create a pull request, you can also see the coverage info:
Don't forget, you can show a coverage badge in your Readme.md
file!
Add the following code to your file.
![Test Coverage](https://{your-gitlab-instance}/{org}/{repo}/badges/{default-branch}/coverage.svg)
Dear Author,
I just finished reading your blog post on showing .NET code coverage rate and unit test status with GitLab CI/CD pipeline, and I must say that I found it to be quite informative and well-structured. The step-by-step instructions you provided, along with the accompanying images, made it easy to follow and understand the process.
One of the major highlights of your post is the clear and concise explanation of how to set up and configure the necessary dependencies for the unit test projects. The inclusion of the example code for the .gitlab-ci.yml file is also beneficial, as it provides a solid starting point for readers looking to implement this solution in their own projects.
I appreciate that you have demonstrated how to view and interpret the unit test and code coverage results within the GitLab interface. The screenshots you provided are helpful for visualizing the expected outcome. Moreover, the tip about adding a coverage badge to the Readme.md file is a nice touch, as it allows for easy visibility of the project's test coverage.
As for areas of improvement, I noticed that the blog post does not mention any potential limitations or caveats that users might encounter when implementing this solution. It would be helpful to include a brief discussion on any known issues or limitations, as well as possible workarounds or alternative approaches when faced with these challenges.
Furthermore, while the blog post is focused on GitLab CI/CD pipeline, it might be useful to provide some context or comparison with other CI/CD platforms, such as GitHub Actions or Azure DevOps, for readers who may be considering different options for their projects.
Overall, I commend you for writing an insightful and practical blog post on this topic. Your expertise and effort in presenting this information are evident, and I believe many developers will find it valuable as they seek to improve their code quality and testing practices. Keep up the great work!
Best regards,
[Your Name]