Dependency compatibility checker - #773
Conversation
6fd45d3 to
5c75493
Compare
There was a problem hiding this comment.
Not maintainable / really complex to understand what is done here.
What about move it to a python script which we could also test?
There was a problem hiding this comment.
What exactly is to complex? What exactly you want to extract into a python script?
We want to utilize Github Actions matrix builds, if you test all combinations within one action, it will take ages and not run in a parallel?
There was a problem hiding this comment.
Also I think we should include it in our docs build (valuable addition)
There was a problem hiding this comment.
We can at some point, goal of this is to get this kind of checks starting.
Introduce the dependency_compatibility_checker under quality/ with its configuration model and a default config. - config_schema.py validates the config: the set of dependencies, the candidate versions per dependency, optional patches, and optional build flags, then expands them into the cartesian product of version combinations to test. - config.yaml is the source of truth for the matrix: Bazel, rules_cc, rules_python and rules_rust versions, yielding the combinations the nightly job exercises against the root MODULE.bazel. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
generate_matrix.py reads the checker config and emits the list of dependency version combinations as JSON, suitable for consumption as a GitHub Actions matrix. Each entry carries the versions, patches and build flags for one combination. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
This Regex stuff is very brittle, either replace by some parser or enhance the test suite, both positive and negative cases, currently I guess a bracket inside a comment would break the tool
5c75493 to
459c025
Compare
| See the design spec for the full rationale: | ||
| `docs/superpowers/specs/2026-07-24-dependency-compatibility-checker-design.md`. |
There was a problem hiding this comment.
What exactly is to complex? What exactly you want to extract into a python script?
We want to utilize Github Actions matrix builds, if you test all combinations within one action, it will take ages and not run in a parallel?
There was a problem hiding this comment.
We can at some point, goal of this is to get this kind of checks starting.
module_rewriter.py rewrites the root MODULE.bazel for a single version combination by appending single_version_override blocks that pin each dependency to the version under test (and apply patches when configured). Overrides are emitted in buildifier-canonical multi-line form and separated by blank lines so the rewritten file passes the repository's Starlark formatting checks. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
generate_report.py aggregates the per-combination build/test results and renders an HTML report (via report.html.j2) plus a machine-readable JSON summary. Each combination is classified as green (fully compatible, only differing build flags allowed), orange (compatible only with patches) or red (incompatible). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Wire the dependency_compatibility_checker into Bazel with py_binary targets for the matrix/rewriter/report entry points and py_test targets for their unit tests. Tests cover config validation and combination expansion, matrix JSON generation, MODULE.bazel rewriting (with fixtures for plain, single_version_override and git_override files) and report rendering/classification. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Document the purpose of the checker, the config.yaml format, how to run the tools locally via Bazel, and how the green/orange/red classification is derived. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add a scheduled (nightly) + manually dispatchable workflow that drives the dependency_compatibility_checker end to end: - generate-matrix: expands config.yaml into the combination matrix. - build-and-test: for each combination, rewrites MODULE.bazel, then runs bazel mod deps, bazel build //... and bazel test //..., recording the outcome and the stage that failed. Per-combination logs are uploaded as artifacts to aid debugging. - report: aggregates the results into the HTML/JSON compatibility report and fails if any combination is red. All bazel invocations pass --lockfile_mode=off because rewriting MODULE.bazel invalidates the committed lockfile, which would otherwise fail under the repository's --lockfile_mode=error default. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
visibility_guard's parser runs a nested 'bazel query' to enumerate public targets. Under the compatibility matrix the root MODULE.bazel is rewritten, so the committed lockfile no longer matches and the query fails (its exit code was ignored, yielding zero targets and a spurious golden diff). Pass --lockfile_mode=off to the nested query so it resolves the module graph regardless of lockfile staleness. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
No description provided.