After moving from Jira 8 Server to Jira 8 Data Center, our automated test execution status updates stopped working reliably. We use Xray for test management and import JUnit results via REST API from our CI pipeline.
The problem: Test Execution issues created by CI show “In Progress” status indefinitely. When I check individual test runs, some show correct pass/fail results while others are completely missing. This happens randomly - about 30% of CI test imports fail silently.
We’re using this REST call from Jenkins:
curl -X POST https://jira.company.com/rest/raven/1.0/import/execution/junit \
-H "Content-Type: application/json" \
-d @junit-results.xml
In Server, this worked 100% of the time. In Data Center, it’s unreliable. I suspect it’s related to the load balancer or how background jobs process test results across cluster nodes. Our Jira DC has 4 nodes behind an F5 load balancer. How do we ensure test execution imports are properly linked to CI runs across a clustered environment?
Background job processing in Data Center requires proper cluster configuration. Check your shared home directory setup - if nodes can’t access shared files properly, background jobs fail silently. Also, Xray stores temporary import data in the shared home during processing. Slow file system performance or permission issues can cause timeouts that result in incomplete test execution updates. Monitor your cluster’s background job queue to see if import jobs are failing or timing out.
I had similar issues with Xray imports in DC. The problem was that our Jenkins jobs weren’t including the Test Execution issue key in the import request. Without linking the import to a specific Test Execution, Xray tries to create a new one, and in DC this can cause race conditions if multiple nodes process parts of the same import simultaneously. Try adding the test execution key parameter to your REST call so Xray knows exactly which issue to update.
I checked the shared home directory - permissions look correct and all nodes can access it. Our base URL is configured consistently across nodes. The sticky sessions suggestion makes sense - I’ll work with our network team to verify F5 configuration. But I’m still unclear on the best way to link CI runs to Test Execution issues in the API call. Should we pre-create the Test Execution issue or let Xray create it automatically?