CI | NuGet |
---|---|
Helper for converting trx-Testresults (dotnet test --logger "trx"
) to a JUnit-based XML file.
Can be used for CI-scenarios, like CircleCi or GitLab, where as test results JUnit is expected.
When installed as .NET Core Global Tool:
trx2junit {trxFile}
where trxFile is the path to the trx-file.
You can pass more than one trx file, each will create it's own junit xml file.
# handle two files
$ trx2junit a.trx b.trx
Converting 2 trx file(s) to JUnit-xml...
Converting 'a.trx' to 'a.xml'
Converting 'b.trx' to 'b.xml'
done in 0.1234567 seconds. bye.
# for shells that handle wildcard expansion:
$ trx2junit results/*.trx
Converting 1 trx file(s) to JUnit-xml...
Converting 'example.trx' to 'example.xml'
done in 0.1234567 seconds. bye.
If the shell won't handle wildcard expansion, trx2junit
handles the expansion of files in the same directory.
A different location for the JUnit-output can be specified:
# specify different output location
$ trx2junit a.trx --output ../results
# or
$ trx2junit --output results a.trx ../tests/b.trx
For Jenkins JUnit on the testcase the status-attribute is set. By default 1
is set for success, and 0
for failure.
This can be configured via environment varialbes (note: if omitted, the default values will be used):
Status | Variable | default value |
---|---|---|
success | TRX2JUNIT_JENKINS_TESTCASE_STATUS_SUCCESS |
1 |
failure | TRX2JUNIT_JENKINS_TESTCASE_STATUS_FAILURE |
0 |
skipped | TRX2JUNIT_JENKINS_TESTCASE_STATUS_SKIPPED |
not set |
With environment variable TRX2JUNIT_JUNIT_ERROR_MESSAGE_IN_CDATA
set, the error message from a failing test will be repeated in the CDATA-content of the <failure>
element.
See this comment for further info.
With option --junit2trx
a conversion from junit to trx can be performed.
If a given xml-file is not a junit-file, a message will be logged to stderr and the exit-code is set to 1
.
A junit-file is considered valid if it either conforms to junit.xsd or jenkins-junit.xsd.
dotnet tool install -g trx2junit
For CI-scenarios execute before usage:
export PATH="$PATH:/root/.dotnet/tools"
Check also the documentation of your CI-system on how to persist the PATH
between steps, etc.
E.g. in CircleCI you need to run
echo 'export PATH="$PATH:/root/.dotnet/tools"' >> "$BASH_ENV"
In order to install this tool a .NET SDK must be present. Supported SDKs are:
Starting with v2.0.0 it's possible to use the core functionality as standalone package trx2junit.Core
.
The tool (see above) itself is a consumer of that package.
After adding a reference to trx2junit.Core
one can use it in "commandline-mode" like
Worker worker = new();
WorkerOptions options = WorkerOptions.Parse(args);
await worker.RunAsync(options);
or create the WorkerOptions
via the constructor, and pass that instance into RunAsync
of the worker.
To get packages from the development channel use a nuget.config
similar to this one:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="gfoidl-public" value="https://pkgs.dev.azure.com/gh-gfoidl/github-Projects/_packaging/gfoidl-public/nuget/v3/index.json" />
</packageSources>
</configuration>