Connect your CI pipeline to Nexus

Configure Nexus once, add an upload step to your existing pipeline, then check the first result in Jira. Your tests continue to run in your CI environment. No Nexus plugin needs to be installed on your CI server.

You will need: a configured Nexus project, permission to manage its CI keys, access to your pipeline settings, and an existing test job. The upload examples use a Linux runner with Node.js 22 available. Keep your existing checkout, dependency installation and test steps.

If your tests do not produce a results file yet, use the automation setup guide first. If you already use the Nexus Playwright reporter or pytest plugin, give that test job the Nexus environment variables below; do not add a second upload for the same results.

Configure Nexus

1. Open your Jira project, then Project settings → Nexus → CI.
2. Create an API key with a recognisable label, such as GitHub staging. Choose the ingest permission for result uploads if the scope selector is available. Copy the key now: it is shown only once.
3. Copy the results URL from the same page. This is the complete endpoint, not your Jira site address. Do not use the separate CI API URL for a results-file upload.
4. Open an existing Test Case and copy its Automation Key. Put that key in the automated test's name, for example NEX-123: customer can sign in. Use a case in this project that is ready to run, rather than an obsolete case.
5. Note your Jira project key and the environment you want the results associated with. The examples use NEX and staging; replace them with your values.

The project key and report filename are ordinary configuration. The API key is a secret: never commit it, put it in a URL or print it in job logs.

Prepare your test report

Run one small test locally or in your existing pipeline. Configure its reporter to write a supported report file, and check that the file exists after the run. The automation guide gives the commands for each framework and shows where to place the Automation Key.

The snippets below upload results.xml. For Cucumber or Mocha JSON, replace that filename with your actual .json report. The upload CLI detects supported formats. If tests produce several XML files, upload each file separately; do not concatenate XML documents.

Download the upload CLI, save it as nexus-upload.mjs in the root of your test repository, and commit that file with your pipeline change. It has no package dependencies. Check the download against the published checksums if your organisation requires download verification.

Ready to continue: the pipeline checks out nexus-upload.mjs, has Node.js available, and produces a report with at least one test whose key matches an existing Nexus Test Case. Use fresh report output for each job so you cannot accidentally upload a stale file from an earlier run.

Configure your CI platform

Open the instructions for your platform. These are additions to an existing working test pipeline, not replacement pipelines. Run the uploader in the same job and working directory as the report; if you use a separate job, transfer the report as an artifact first.

- name: Send test results to Nexus
  if: ${{ always() }}
  env:
    NEXUS_URL: ${{ secrets.NEXUS_URL }}
    NEXUS_API_KEY: ${{ secrets.NEXUS_API_KEY }}
  run: node nexus-upload.mjs results.xml --project NEX --environment staging

after_script:
  - node nexus-upload.mjs results.xml --project NEX --environment staging

post {
  always {
    withCredentials([
      string(credentialsId: 'nexus-url', variable: 'NEXUS_URL'),
      string(credentialsId: 'nexus-api-key', variable: 'NEXUS_API_KEY')
    ]) {
      sh 'node nexus-upload.mjs results.xml --project NEX --environment staging'
    }
  }
}

sh '''
  set -e
  for report in target/surefire-reports/TEST-*.xml; do
    test -f "$report" || { echo "No Surefire XML reports found"; exit 2; }
    node nexus-upload.mjs "$report" --project NEX --environment staging
  done
'''

- bash: node nexus-upload.mjs results.xml --project NEX --environment staging
  displayName: Send test results to Nexus
  condition: succeededOrFailed()
  env:
    NEXUS_URL: $(NEXUS_URL)
    NEXUS_API_KEY: $(NEXUS_API_KEY)

after-script:
  - node nexus-upload.mjs results.xml --project NEX --environment staging

Verify the first delivery

1. Run a small pipeline on a branch that can access the configured secrets.
2. Confirm the test job produced the expected report. Open the Nexus upload step and check for an accepted response. HTTP 202 means queued for processing, not that every result has been recorded.
3. Return to Project settings → Nexus → CI and refresh the delivery log. Check the processed outcome: matched, unmatched or skipped results.
4. Open the matched Test Case's execution history. Check its status, duration and target environment against your test output.
5. In a safe test branch, run a deliberately failing test and confirm that its failure is also delivered. The CI test result must remain failed.

You are finished when: one known case has the expected recorded result, an intentional failure also reaches Nexus, and the team knows where to investigate delivery errors.

Troubleshooting

For help, contact support with the platform, upload timestamp and error message. Do not include the API key.

Optional settings and next steps

Start with the project and environment. Once the first delivery works, add --test-set NEX-25 to record against a specific cycle, or --component web to identify a component. Replace example keys with your own. The CLI reads build/commit metadata from common CI environment variables; --build and --commit can override them.

Keep result-file ingestion separate from CI API operations such as recording a deployment: those use the CI API URL, an appropriate key scope and a JSON operation body. See the API reference for that configuration, request limits and all supported formats.

• Configure your automation framework
• Downloads and alternative integration helpers
• Review release readiness