This step in the tutorial demonstrates Testspace's integration with GitHub workflows for publishing test results. Testspace also works with many other popular CI systems. Refer to the Add to CI help article for details.
The example uses the Github repo created based on the sample in the Setup section of the tutorial.
Let's use the GitHub workflow
- to manually invoked automation that will publish pre-canned test results
GitHub Workflows supports many different types of events that will trigger a workflow, however, for this tutorial, we wanted to make things easy and interactive. For this reason, a workflow dispatch event is used versus a more common event such as push.
workflow dispatchevent to manually execute the GitHub Workflow
To execute the GitHub workflow go to the
Actions tab. Select the CI workflow under
- On the far right click the
Run workflowbutton, use the
Branch: mainand click
- Watch the
CIworkflow execute using the GitHub UI
- When the automation is complete, switch to your Testspace project
- Explore Testspace, starting at the
Testspace automatically tracks the branch workflow. Go ahead and create a branch and watch Testspace track it with a matching space. Pull requests are also supported, along with merged and deleted branches.
Remember to execute the automation using the GitHub UI.
The following file content is used in this basic example for publishing automated testing results. Note that the test results are pre-canned (aka fake) and used for demonstration purposes only.
There are two files (
results.xml) required for publishing results:
The following content into the
NOTE if using a private repo a Testspace
tokenis required. Follow these additional steps.
if: always()ensures test results are uploaded even in the event of a workflow failure.
- Refer here for details on the
For simplicity we are using pre-canned test results.
tips section provides additional examples for common use-cases.
Results can be organized into folders:
sub-folders can also be used with a forward slash
When using a matrix it is recommended to use a
folder to store the results specific to each matric entry.
For more information on publishing features, refer to the Push Data section of the help documentation:
- Adding Code Coverage
- Organizing results based on repo source folders
- Passing wildcards, sub-directories, etc., for finding results files
- Adding custom metrics
See Tools Support for language-specific information.
This section covered the simplicity of publishing test results from automation based on GitHub workflows:
- Single line command to publish results
- Built-in branch workflow support for branching, pull requests, and forks
- Additional useful information related to the health of the build can also be included, such as code coverage, custom metrics, etc.
A Testspace setup action is provided:
If the repo being used is private there are additional steps required:
- Copy your Testspace User access-token
- Create a secret, in your repo settings named
TESTSPACE_TOKENwith value being your Testspace token.
- Update the
ci.ymlfile, adding the
tokeninput as shown below
Note that the
domain action parameter for setup-testspace is using a github context variable called
github.repository_owner. This variable returns a string reflecting the name of the GitHub organization. When installing the Testspace app using the GitHub Marketplace the Testspace organization name matches the GitHub organization name. If the Testspace subdomain is changed the
domain setup parameter needs to be updated as well.