Skip to content

v0.2.0

Latest

Choose a tag to compare

@github-actions github-actions released this 21 Sep 09:48
· 12 commits to main since this release

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 gitlab

Configure 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 /qg comments, 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 file attributes 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.0

Update 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@3b0cf7d8a33215d5a3bb5521b4e0e41c18e8cb7c
qg generate
qg validate

Deploy 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 summary as 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.

Contributions: #72, #75, #77, #76.

Full changelog: v0.1.10 → v0.2.0