Repository navigation
Quality Graph 0.2.0 brings first-party GitLab support, reports that explain why checks failed, and more reliable GitHub dashboards across retries and declaration changes.
Your checks remain ordinary repository commands. Quality Graph handles orchestration, result collection and review governance around them.
GitLab, out of the box
The new quality-graph-gitlab package provides a supported installation and onboarding path:
uv tool install quality-graph-cli==0.2.0 --with quality-graph-gitlab==0.2.0
qg init --provider gitlabConfigure the instance URL and publisher account ID, then run qg generate and qg validate.
- Generate native GitLab jobs, dependencies and result artifacts for merge-request and branch pipelines.
- Publish one managed MR summary with execution and effective results, findings, job-log links and owned labels.
- Approve or revoke quality findings at node, file or finding level through
/qgcomments, without rerunning the checks just to update their effective status. - Bind results to the exact project, commit, pipeline and job, including retries. Missing or mismatched evidence cannot establish success.
- Keep write credentials in a protected publisher project; consumer and fork code runs without the publisher token.
- Configure GitLab.com or self-managed instances, including nested namespaces and custom API endpoints.
The MR summary currently provides a table and comment-based controls; it does not render the GitHub dependency diagram or clickable approval controls. Executable release flows, merged-results pipelines and merge trains are not supported by this first GitLab integration.
Setup and migration guide · Runnable example
Reports with useful failure details
Producer report v0 lets custom checks emit metrics, findings, diagnostics and notes without constructing framework identity, provenance or approval controls. Quality Graph supplies that trusted metadata during collection. Full native result inputs remain supported.
- JUnit reports include test names and assertion traces, with full test/failure/skipped counts.
- Repository-relative JUnit
fileattributes enable file-level approvals. - Large JUnit reports preserve full totals while constructing at most 10,000 findings and 100 diagnostic traces, with explicit omission counts.
- The repository check runner preserves separate in-process and Docker results. Infrastructure errors take priority over test traces, so a Docker health-check or cleanup failure remains visible after hundreds of test failures.
- Command output is rendered as diagnostic detail instead of duplicating failure text in the summary.
Producer contract and adapters
GitHub dashboards you can trace back to the job
- Authoritative retry results: artifacts are checked against the actual workflow job attempts. Retained results from an older execution cannot silently stand in for the current job.
- Direct log links: each Dashboard row links to the corresponding GitHub job, including the admitted attempt after a retry.
- Additive declaration changes: a PR can introduce checks while preserving every existing required check and governance setting. Added checks appear in the final Dashboard and must provide valid results; missing or failed results prevent success.
- Clearer publication failures: if artifact validation fails, the fallback explicitly distinguishes native job conclusions from verified results. Successful jobs alone do not make the aggregate successful.
Migration and compatibility
Upgrading from 0.1.10 does not require rewriting qg.yaml or replacing GitHub Result v0. GitLab adds Result v1 for its own provenance; producer report v0 is a separate, optional collection input. The source-file rename to qg.yaml happened in 0.1.8 and is not a new requirement introduced by this release.
Upgrade the CLI and each provider you use together to 0.2.0. For GitHub installations:
uv tool install quality-graph-cli==0.2.0 --with quality-graph-github==0.2.0Update both provider.configuration.runtime.action and publisher-action to the immutable release commit, regenerate the workflows and validate them:
runtime:
action: alchemmist/quality-graph@3b0cf7d8a33215d5a3bb5521b4e0e41c18e8cb7c
publisher-action: alchemmist/quality-graph@3b0cf7d8a33215d5a3bb5521b4e0e41c18e8cb7cqg generate
qg validateDeploy the updated publisher through the trusted base branch before relying on new declaration-migration behavior. Changing its pin only inside a feature PR does not replace the publisher already running from the base branch.
Behavior changes to account for:
- Retry validation is stricter. Previously accepted stale or mismatched artifacts can now fail the aggregate. Rerun the affected checks to produce current evidence; do not reuse artifacts from another attempt.
- JUnit file paths must be repository-relative. Absolute paths and parent traversal are rejected. Configure report producers accordingly; source locations use line 1 because JUnit producers do not share a line-number convention.
- A passing report cannot hide a failed command. In particular, a JUnit report with no failed cases combined with a nonzero command exit is classified as a command failure rather than an approvable quality failure.
- Raw exit-code output moved to diagnostics. Integrations that consume
summaryas a copy of stdout should read diagnostic detail instead.
For GitLab, set a positive publisher-user-id before generating MR publication jobs, use HTTPS outside loopback, and configure the protected publisher before enforcing merge checks. Moving from GitHub also requires replacing GitHub-specific setup actions with shell commands and explicitly retiring the old workflows. The GitLab guide covers the supported differences.
Packaging and validation
All five distributions are published at 0.2.0: core, CLI, Python gates, GitHub and GitLab providers. GitLab is installed separately and does not require the GitHub provider.
The release adds a stateful GitLab HTTP testkit and a real local GitLab/Runner laboratory covering approvals, retries, cancellations, explicit skips, erased artifacts, head changes and fork MRs. Published CLI and GitLab packages were also installed together in a clean environment and passed initialization, generation and validation smoke checks.