Test Reports, Coverage, JUnit, Code Quality, Browser Performance, Accessibility, and Pipeline Feedback: Configuration, Design Choices, and Tradeoffs

1. Start from the evidence contract

Before selecting a widget or threshold, write down the contract: which source SHA is measured, which tool/version generated the result, what file/schema GitLab parses, what tool exit status means, who owns a failure, how long raw evidence remains available, and whether the result is advisory or blocking. This avoids building policy around UI behavior that may have different tier or aggregation semantics.

Keep CI_PIPELINE_SOURCE and CI_COMMIT_SHA in the evidence packet so the report cannot be separated from the pipeline context that generated it.

2. Blocking versus advisory

Do not use allow_failure: true reflexively to “make the pipeline green.” If a tool is advisory, say so explicitly and preserve the finding. If it is blocking, do not neutralize its exit code merely to keep a widget visible—report artifacts are uploaded independently of job success.

3. One monolithic report versus per-shard reports

Chapter 17 introduced sharding. The report architecture must follow. JUnit can accept multiple files/patterns and GitLab can present multiple unit-test reports. Coverage visualization can merge multiple reports collected by wildcard. Code Quality can combine findings from multiple report-producing jobs. Browser Performance is different: GitLab cannot display combined results from multiple browser-performance reports.

4. UI summary versus raw artifact

The UI is optimized for review speed: failed test names, coverage deltas, changed-line annotations, quality findings. Raw evidence is optimized for reconstruction: full XML/JSON, tool version, parser input, checksums, and sometimes screenshots or HTML. Use both when the evidence matters.

However, storing the same report under both artifacts:reports and artifacts:paths has storage implications. Define a retention window and access level appropriate to the data. If a report contains sensitive URLs or stack traces, restrict artifact access rather than assuming the MR widget is the only exposure path.

5. Coverage threshold versus trend and context

Coverage is a measurement of exercised code according to a specific tool and denominator. It is not a direct measurement of correctness. A project can raise coverage while removing meaningful assertions, excluding difficult files, or testing trivial branches. Treat a threshold as one guardrail among several.

6. Tier and presentation choices

7. Child pipelines and report boundaries

Do not design parent/child pipelines on the assumption that all child report artifacts combine automatically in the parent. Current GitLab documentation notes that combined parent reports from child-pipeline artifacts are not generally supported. Coverage reports from child pipelines can still appear as MR diff annotations, but the underlying artifact relationship is separate. Preserve child pipeline/job IDs in the evidence packet.

8. Retention, parser timing, and artifact access

Report processing can happen after the job finishes. Coverage visualization, for example, is processed after pipeline completion. A blocking manual job can delay when coverage annotations appear. Artifact expiry may remove raw evidence later even though a reviewer remembers the UI summary. Set retention according to review/audit needs, and document which UI elements depend on retained artifacts versus persisted parsed metadata.

Current YAML also lets projects restrict artifact access. Treat report artifacts as data assets: classify them, avoid secrets, and set access intentionally.

9. Worked decision table

10. Anti-patterns

Knowledge check

Official references and version notes

Documentation verification date: 2026-09-12. JUnit/unit-test reports, coverage percentage extraction, Cobertura/JaCoCo coverage visualization, Code Quality report import, and Accessibility reports are available on Free/Premium/Ultimate. Browser Performance reports are Premium/Ultimate. Code Quality's built-in CodeClimate-based template was deprecated in GitLab 17.3 and is planned for removal in GitLab 19.0; current guidance is to integrate a supported tool's report directly. Current Code Quality documentation recommends direct integration from supported tools; the CodeClimate-based built-in template is deprecated and planned for removal in GitLab 19.0.

• Unit test reports — official reference.
• Unit test report examples — official reference.
• Code coverage — official reference.
• Coverage reporting — official reference.
• Coverage visualization — official reference.
• Cobertura coverage visualization — official reference.
• Code Quality — official reference.
• Accessibility testing — official reference.
• Browser performance testing — official reference.
• Artifacts reports types — official reference.
• Job artifacts — official reference.
• CI/CD YAML syntax reference — official reference.

Current assumptions used in this chapter: Version-sensitive YAML, Runner/executor behavior, APIs, security features, policy controls, tiers, and deprecations must be verified against the exact GitLab, GitLab Runner, tool, and external-system versions used in production. Preserve the exact project/ref/SHA, compiled configuration, pipeline/job IDs, runner/tool versions, and external target evidence used for reproducible work.