However, to look up specifically which test failed and why, we need to look in the logs. For a single test this is not a problem, but if we have hundreds of tests, we don’t have the time to scroll through thousands of log lines to find the test that failed. We also don’t immediately see what percentage of tests failed. Fortunately, Azure DevOps provides an interface here to provide test results in JUnit XML format. To make use of this feature, we need to convert the output of go test
into this format. Luckily, someone else has already done this work for us and written a corresponding go tool: https://github.com/jstemmer/go-junit-report
. We are also interested in test coverage. There is also an interface from Azure DevOps and ready-made tools for converting it to the right format.
For this whole complex process, we create a bash task which will do the following: first it will download the necessary tools, then it will run the tests, remembering the return code for later. This is because we want to use the return code of go test
as the return code of the whole step, so that Azure DevOps knows whether the step failed or not. But before that, we need to prepare the report and coverage, both in case of success and failure. Afterwards, we add the two tasks PublishTestResults
to the pipeline. Here it is important to add condition: succeededOrFailed()
. Normally, subsequent steps are not executed if a step fails (i.e. the default value is condition: succeeded()
) but with condition: succeededOrFailed()
they are executed even if previous steps failed, but unlike condition: always()not
if the pipeline was manually aborted.
Side note if the builds are going to be run on a self-hosted build agent: the PublishCodeCoverageResults
task expects the build agent to have a .NET runtime installed.
Here now the finished pipeline: