Keep the existing runner, image and dependency setup.
GitLab and Jira test automation
Connect GitLab CI test evidence to Jira
Keep test execution in GitLab CI. Deliver the resulting report to Nexus, then follow Jira cases, cycle outcomes and defects without reconciling a separate spreadsheet.
GitLab CI/CD variablesReport delivery checksJira execution evidence
How it works
Prepare a fresh report in the existing test job
Begin with a GitLab job that already runs your tests. Configure a supported report, such as JUnit XML, and identify its actual filename and working directory. Download the Nexus upload CLI as described in the GitLab setup guide and keep Node.js available in the job image.
The uploader and the tests need access to the same report. If delivery runs in a separate job, pass the file through artifacts. When a framework produces several XML files, upload them individually rather than concatenating XML documents. If your job uses the Nexus Playwright reporter, let the reporter deliver the result instead of adding a second file upload.
Use fresh report output from the current test job.
Confirm Node.js is available to the upload command.
Choose one delivery route for each report.
Implementation guide
Separate CI secrets from execution context
In Nexus CI settings, create an ingest key with Send results permission and copy the complete results URL. In GitLab Settings, CI/CD, Variables, add NEXUS_URL and NEXUS_API_KEY. Mask the key and hide it where available. If you protect a variable, use a permitted protected branch or tag for the first verification.
The project key, environment and optional cycle identify where the evidence belongs. Each result must match an existing Ready Jira Test Case by Automation Key or issue key. Check that mapping with one small test before sending a large suite. Keep credentials out of test names, source files, URLs and pipeline logs.
Use the full results endpoint from Nexus settings.
Use an ingest key with the intended delivery permission.
Check protected-variable access for the branch or tag.
Match one known case before expanding the upload.
Implementation guide
Understand what after_script does and does not prove
The documented GitLab upload example adds the sender to after_script in the existing test job. This lets delivery run after ordinary test failures. GitLab starts that section in a fresh shell, so values exported only by the test script are not a reliable way to supply secrets. Use the CI/CD variable settings instead.
An after_script failure does not change a successful job exit status. A green pipeline therefore does not prove Nexus received its report. Check the upload log and the Nexus CI delivery log explicitly. Timeouts or runner failures can also prevent delivery. If a previous setup error produced no report, diagnose that condition separately from test failures and matching errors.
Append to an existing after_script block instead of replacing it.
Supply secrets through job variables, not temporary shell exports.
Inspect sender output even when the pipeline is green.
Confirm HTTP acceptance and matched execution in Jira.
Implementation guide
Keep GitLab.com dispatch and self-hosted execution distinct
Nexus Run in CI has a direct connection for GitLab.com using a pipeline trigger token. The dispatch path has been verified on the development build; check the installed app version before making it part of release sign-off. Nexus sends only the administrator-selected project, cycle, environment and build context. The pipeline retains its own Nexus ingest key as a CI secret.
For GitLab.com dispatch, follow the documented setting for the minimum role allowed to use pipeline variables and map the incoming nexus_cycle and environment values into the sender. Pipeline context can be visible on the pipeline page, so do not forward secrets as context. Self-hosted GitLab uses the customer-hosted Nexus runner for the documented Jira-triggered execution route. Ordinary result uploads still run from your own infrastructure.
Use the GitLab.com service example for direct Run in CI.
Check pipeline-variable permissions before requesting a cycle.
Map incoming context to the result destination.
Use the customer-hosted runner guide for self-hosted dispatch.
Questions buyers ask
Frequently asked questions
Why is GitLab green when the upload failed?
GitLab after_script errors do not change a successful job exit status. Inspect the sender log and Nexus delivery log to confirm delivery.
Can results from a failed GitLab test job reach Jira?
Yes, when the report exists and the upload section runs. Timeouts, runner failures and missing reports need separate investigation.
Does the Nexus GitLab.com connection include self-hosted GitLab?
The documented direct connection is for GitLab.com. Self-hosted Jira-triggered execution uses the customer-hosted Nexus runner; tests and result delivery remain in your infrastructure.
Test the workflow with a real Jira project
Start with one requirement, one cycle and one release decision.