Test Reports, Coverage, JUnit, Code Quality, Browser Performance, Accessibility, and Pipeline Feedback: Concepts, Architecture, and Mental Model

1. The practical problem: a widget is not the evidence

Chapter 23 ended with a strong distribution chain: exact source SHA, producer pipeline, immutable package version or image digest, and consumer verification. Quality feedback needs the same discipline. A test framework can exit non-zero but fail to write its report. It can also exit zero while a hand-authored or stale report contains failures. GitLab can ingest a valid report and render a useful widget, but that widget is a view over evidence, not the evidence itself.

The chapter therefore separates three things that are often accidentally collapsed: tool execution semantics, report ingestion semantics, and delivery policy. The first answers whether the command succeeded. The second answers whether GitLab parsed structured evidence. The third answers whether a result is advisory or blocking.

2. Terms before YAML

3. Mental model: execution → report → parser → feedback → policy

A tool reads a known source revision and returns both a process result and, ideally, a structured file. The runner uploads that file. GitLab validates and parses it according to the declared report type. The UI then renders the parsed data in a Tests tab, merge-request report, diff annotation, or specialized widget. Finally, your pipeline policy decides whether the evidence is blocking, advisory, or merely informational.

The two arrows from the tool are intentional: exit status and report data are independent channels. A sound operating model checks both.

4. State to capture before changing anything

5. Current report capabilities and boundaries

6. File and aggregation constraints are part of design

Current unit-test documentation requires JUnit XML files smaller than 30 MB each and a total under 100 MB per job. JUnit declarations accept files, arrays, and filename patterns but not bare directories. Cobertura visualization currently limits a report file to 10 MiB and documents a 100-<source>-node limit. Multiple coverage reports can be collected with wildcards and GitLab merges them for visualization.

Not all report types aggregate the same way. Browser Performance cannot display combined results from multiple report artifacts. Reports from child pipelines can produce coverage diff annotations, but report artifacts are not generally combined back into parent pipelines. Design fan-out/fan-in based on each report type's actual ingestion semantics, not on an assumption that every JSON/XML file will merge.

7. Raw reports and UI summaries serve different jobs

artifacts:reports tells GitLab how to ingest structured data. If you also need the report file in the artifact browser, add it to artifacts:paths. That may increase storage, so set an explicit retention period that preserves the evidence for your review/audit horizon. Report access can also be restricted with artifact-access settings; a test report can contain filenames, stack traces, URLs, or other information that should not be publicly downloadable.

8. Read-only inspection first

printf 'source=%s ref=%s sha=%s pipeline=%s job=%s\n' \
  "$CI_PIPELINE_SOURCE" "$CI_COMMIT_REF_NAME" "$CI_COMMIT_SHA" \
  "$CI_PIPELINE_ID" "$CI_JOB_ID"

# Inspect report files without modifying them.
ls -lh reports/ 2>/dev/null || true
sha256sum reports/* 2>/dev/null || true

# Validate XML syntax locally before blaming GitLab ingestion.
python - <<'PY2'
from pathlib import Path
import xml.etree.ElementTree as ET
for p in Path('reports').glob('*.xml'):
    ET.parse(p)
    print('valid_xml', p)
PY2

9. Common misconceptions

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. JUnit report files currently have documented size limits of 30 MB per individual file and 100 MB total per job. Cobertura visualization currently documents a 10 MiB file limit and a 100-source-node limit. Report-type limits should be rechecked before production use.

• 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.