Trace tab

The Trace tab of the CI/CD Pipelines screen (/pipelines?tab=trace) answers a question that usually takes an afternoon of digging: “what actually tested this deploy?”

How to use it

Paste a commit SHA or a branch name into the box and press Enter (or click Trace).

Input	Matching
Commit SHA	Prefix match, six characters or more — the short SHA from a deploy log or git log works.
Branch name	Exact match, case-insensitive.

What comes back

Two groups of results, in one list:

1. CI runs — the pipeline-triggered runs for that commit or branch, each with its verdict, build number, result counts, duration, a link to the CI build, and a link to the full Testver report.
2. Other Testver runs on the same commit — manual re-verifications, suite runs someone kicked off from the UI, scheduled runs. These aren’t in the CI history, but they did test that code, so leaving them out would give a misleading answer.

That second group is the point of this tab. “The pipeline passed” and “everything that ran against this code passed” are different statements, and during an incident the difference matters.

Tip

Deploy logs and release notes usually record the commit SHA. Copy it straight into this box after a bad release to see, in one screen, whether the code was gated at all — and by what.

When results are empty

• The trigger didn’t carry a commit. A plain testver trigger --mapping … with no --sha/--branch records no commit, so it can’t be traced. The generated CI configs always send them; add --sha when triggering from your own scripts.
• The project isn’t a git repository, so Testver has no commit metadata to record against runs.
• The SHA is too short — six characters is the minimum, to avoid matching half your history.

Related

• CI/CD Pipelines overview — how trigger metadata gets recorded.
• CI Runs tab — browse runs by pipeline, branch, and environment instead.
• Results — the full report for any run in the results list.
• Git — the commit history the SHAs come from.