Skip to main content

Publish

This step demonstrates publishing automated test results into the Standalone project and space created in Setup.

tip

Prefer wiring results into GitHub Actions directly? See Using a Connected Repo for the CI-integrated walkthrough — everything below still applies to a Connected project too, just without the manual testspace command.

Install Client​

As a prerequisite to pushing test content the Testspace client console utility is required to be installed on your host computer. Refer to the client installation instructions for Windows, Linux, and macOS computers.

Verify installation:

$ testspace --version

Push Data​

For simplicity, create a file called results.xml with the following pre-canned test results:

<?xml version="1.0" encoding="UTF-8"?>
<testsuites name="example" tests="2" failures="1" time="2.0">
  <testsuite name="Hello Automation">
    <testcase classname="Hello Automation" name="Test Case One" time="1.00"/>
    <testcase classname="Hello Automation" name="Test Case Two" time="1.00">
      <failure type="Exception" message="Something unexpected happened"/>
    </testcase>
  </testsuite>
</testsuites>

Using the newly created file, push data to the server:

$ testspace results.xml YOUR_TOKEN:@YOUR_ORG.testspace.com/tutorial/main
  • Update YOUR_ORG to the name you picked when signing up to Testspace (e.g. myOrganization)
  • Update YOUR_TOKEN to your Project push token or your User access-token
  • tutorial/main are the project/space names from Setup — update if you used different names

Config​

If appropriate you could do a one time config:

$ testspace config url YOUR_TOKEN:@YOUR_ORG.testspace.com/tutorial/main

Then pushing looks like:

$ testspace results.xml

For setting options see:

$ testspace --help config

Explore​

Switch to your Testspace project and explore, starting at the Current tab — you should see the pre-canned results just pushed.

From CI​

The same testspace command works from inside a CI job, not just run by hand — swap the local results.xml for wherever your CI writes results, and this runs on every build. A Standalone project publishes automated results exactly like this from any CI system (GitHub Actions, Jenkins, CircleCI, anything that can run a shell command).

info

Don't hardcode YOUR_TOKEN directly in a checked-in CI job definition — that exposes the credential in your repo/build logs. Store it as a masked secret (e.g. a GitHub Actions encrypted secret) and reference it as an environment variable instead, the same way Publish via CI does for a Connected project's token.

What a Standalone project doesn't do automatically is track branches or pull requests for you — every push targets the space you specify explicitly. If you want Testspace to automatically create and manage a space per branch and track PRs, that's what a Connected project adds — see Using a Connected Repo.

Pro Tips​

For more information on publishing features, refer to the Push Data section of the help documentation:

Recap​

This section covered publishing test automation results to a Standalone project:

  • Installing the Testspace client
  • Option for configuring the Testspace client
  • Pushing data by hand, or from any CI system
  • What a Connected project adds on top: automatic branch/PR tracking