fix(plugin-testops): Send the CI descriptor TestOps actually expects - #888
Closed
todti wants to merge 2 commits into
Closed
fix(plugin-testops): Send the CI descriptor TestOps actually expects#888todti wants to merge 2 commits into
todti wants to merge 2 commits into
Conversation
todti
force-pushed
the
fix/testops-ci-descriptor
branch
from
August 25, 2026 17:17
c6ffe0c to
a2862fa
Compare
2 tasks
todti
force-pushed
the
fix/testops-ci-descriptor
branch
from
August 25, 2026 17:22
a2862fa to
69190b0
Compare
Allure Report Summary
|
Allure perf metricsGenerated at:
Artifacts: allure-perf-metrics |
Uploading results from an Azure DevOps pipeline produces a Job in TestOps
that is named `<projectGuid>_<definitionId>` instead of the pipeline name,
and that cannot be triggered back from TestOps — the run fails with
"build server is not configured for job". These look like one bug but are
two independent ones.
`startUpload()` sent the CI block as `{ name: ci.type }`, while TestOps
identifies the CI by `type` and `endpoint` and ignores anything else. With
neither of them present it cannot tell which build server integration the
job belongs to, so the job is stored without one — and the unknown property
is dropped without an error, so the upload succeeds and nothing hints at the
problem until someone presses Run. This is not Azure-specific: the endpoint
was never sent for any CI.
The job name is a separate defect: `job.name` was set to `ci.jobUid`, and
`ci.jobName` (`Build.DefinitionName`, or `Release.DefinitionName` for classic
releases) was never sent. Triggering itself relies on `job.uid`, which already
has the shape TestOps parses.
- `ci: { type, endpoint }` instead of `ci: { name }`. The endpoint is the origin
of `ci.jobUrl` — enough for TestOps to recognise the integration, and unlike
`SYSTEM_COLLECTIONURI` it carries no trailing slash.
- `job.name` falls back to the uid only when the CI reports no name, and
`job.url` is sent.
- `jobRun.name` and `jobRun.url` are sent; TestOps stores both and refreshes
them on every upload.
- `circle` and `amazon` are reported under the names TestOps uses for those
integrations, `circleci` and `aws`. The job uids both detectors produce
already match what it expects. `drone` stays unmapped: TestOps has no
matching integration type.
Jobs TestOps already knows keep their name and their integration, so jobs
created before this fix have to be re-created there.
todti
force-pushed
the
fix/testops-ci-descriptor
branch
from
August 26, 2026 15:46
69190b0 to
5169504
Compare
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context
Uploading results from an Azure DevOps pipeline produces a Job in TestOps that
<projectGuid>_<definitionId>instead of the pipeline name, andThese look like one bug but are two independent ones.
The job is never bound to a build server.
startUpload()sent the CI block as{ name: ci.type }, while TestOps identifies the CI bytypeandendpointand ignores anything else. With neither of them present it cannot tell which build server integration the job belongs to, so the job is stored without one — and the unknown property is dropped without an error, so the upload succeeds and nothing hints at the problem until someone presses Run. This is not Azure-specific: the endpoint was never sent for any CI, so build server binding never worked anywhere.The job name was the uid.
job.namewas set toci.jobUid, andci.jobName(Build.DefinitionNameon Azure,Release.DefinitionNamefor classic releases) was never sent. Triggering itself relies onjob.uid, which already has the shape TestOps parses — so the name is a display defect rather than the reason runs fail.What changed
ci: { type, endpoint }instead ofci: { name }. The endpoint is the origin ofci.jobUrl— enough for TestOps to recognise the integration, and unlikeSYSTEM_COLLECTIONURIit carries no trailing slash.job.namefalls back to the uid only when the CI reports no name, andjob.urlis sent.jobRun.nameandjobRun.urlare sent; TestOps stores both and refreshes them on every upload.SYSTEM_COLLECTIONURIalways ends with one, and the URLs were built by concatenation. Harmless while nothing read them, but the job URL is stored once and never refreshed.circleandamazonare reported under the names TestOps uses for those integrations (circleci,aws). The job uids both detectors produce already match what it expects, so the type name was the only thing missing.Known limitations
dronestill resolves to no integration type: TestOps has none matching it.Checklist