Keep the working checkout, dependency and test steps.
GitHub Actions and Jira testing
Bring GitHub Actions test results into Jira
Your GitHub Actions workflow runs the tests. Nexus connects its results to Jira cases and cycles, so delivery teams can inspect automated evidence alongside manual testing.
GitHub repository secretsFailed-test evidenceJira cases and cycle context
How it works
Decide which step owns result delivery
Start with an existing workflow that checks out the repository, prepares dependencies and runs your tests. If you already use the Nexus Playwright reporter, expose the Nexus variables to that test step and let the reporter send results. Otherwise, configure a supported report file and use the standalone upload CLI or packaged GitHub action.
Choose one delivery method for each report. The GitHub Actions setup guide shows where to place an upload step. Keep it in the same job and working directory as the report. If a separate job performs delivery, transfer the report as an artifact first rather than assuming another runner has the file.
Use the reporter or a report-file uploader for the same run.
Confirm the exact report path before configuring delivery.
Transfer artifacts explicitly when results cross job boundaries.
Implementation guide
Configure Nexus matching and GitHub secrets
Create a Nexus CI ingest key with Send results permission and copy the complete results URL. Store NEXUS_URL and NEXUS_API_KEY as repository Actions secrets, then reference them only in the step that needs delivery. The key is a Nexus credential rather than an Atlassian account token.
Each reported test needs an Automation Key or issue key matching an existing Ready Test Case in the intended project. Test naming alone does not create Jira cases. Include the project key and environment in your delivery configuration, and an existing cycle when you want those executions grouped together. Test from a trusted branch first: forked pull-request workflows may not have access to your secrets.
Store credentials in Settings, Secrets and variables, Actions.
Never commit a key or print it in a job log.
Check case readiness and matching keys before the first run.
Check secret availability for the workflow event and branch.
Implementation guide
Deliver failures without hiding the failed test
A report from a failed test is often the evidence the Jira team most needs. For file uploads, the documented GitHub example uses if: ${{ always() }} on the delivery step so it can run after a failed test step. Keep the original test failure visible; successful delivery must not turn a failing test run into a pass.
Check that the report was actually produced. An earlier checkout, dependency or setup failure may leave no file to upload. Use fresh output for every job so a stale report cannot be mistaken for the current run. For upload errors, inspect the sender log and Nexus delivery log separately from the test outcome.
Run the delivery step after a failed test where a report exists.
Retain the original test status for pipeline decisions.
Treat a missing report as a separate setup problem.
Verify the matched Jira execution rather than relying on a green upload step.
Implementation guide
Optionally request the workflow from a Jira cycle
Nexus Run in CI provides a connection for GitHub Actions. An administrator configures the repository, branch, workflow and an appropriately scoped GitHub token, then chooses which cycle context values to send. This dispatch path has been verified on the development build; confirm the installed app version before relying on it in a release process.
Declare every selected context value as a workflow_dispatch input with its exact name, such as nexus_project, nexus_cycle and nexus_environment. Map the values into the result sender so evidence returns to the requested cycle. The Nexus ingest key stays in GitHub secrets and is not sent as a dispatch input. GitHub does not return a run ID for this request: inspect the Actions tab and verify the result in Jira.
Follow the Run in CI workflow example rather than guessing input names.
Declare every context input selected in the connection.
Keep the Nexus ingest key in the CI secret store.
Inspect the Actions run and the Jira delivery evidence.
Questions buyers ask
Frequently asked questions
Can a failed GitHub test run still send results to Jira?
Yes, when it produced a supported report and the delivery step is configured to run after failure. Keep the original test failure visible.
Why does GitHub reject a Nexus dispatch input?
Check that every context value selected in the Nexus connection is declared under workflow_dispatch inputs with exactly the same name.
Is HTTP 202 proof that Jira recorded every test?
No. It means accepted for background processing. Check the Nexus delivery log and matched Test Case execution.
Test the workflow with a real Jira project
Start with one requirement, one cycle and one release decision.