fix: return a valid canonical reproducible form from helm_import_repository#285
Merged
abrisco merged 1 commit intoJun 3, 2026
Merged
Conversation
ifutivic
force-pushed
the
fix/import-canonical-reproducible-form
branch
from
c1ca5ad to
091a7b2
Compare
The repository rule implementation returns the dict it considers the "canonical reproducible form" of the repo. Bazel compares each returned attribute against the declared one and emits a DEBUG message suggesting the user add any that differ. `url` is mutually exclusive with `repository`/`chart_name`/`version`, but the implementation returned all of them unconditionally. As a result: - importing via `url` suggested adding `chart_name`/`version` - importing via `repository` suggested adding `url` Both suggestions are rejected by the rule's own argument validation, so the DEBUG message is confusing and unactionable (see periareon#189). Return only the attributes that match the source type that was actually used so the suggested reproducible form is always a valid re-declaration. Fixes periareon#189
ifutivic
force-pushed
the
fix/import-canonical-reproducible-form
branch
from
091a7b2 to
ee0849b
Compare
Contributor
Author
Contributor
Author
|
Immediately after opening this PR I realized that rules_helm doesn't support the new repo_metadata return value. I stacked a second PR on top of this one which adds that as well: #286 |
abrisco
pushed a commit
that referenced
this pull request
Jun 3, 2026
> [!NOTE] > Stacked on #285. That PR fixes the *contents* of the reproducibility dict, this one changes the *mechanism* used to return it. Review/merge after #285 (or together). ## Issue Bazel 9 deprecates returning a bare dict from a repository rule implementation in favor of [`repository_ctx.repo_metadata`](https://bazel.build/rules/lib/builtins/repository_ctx#repo_metadata). Beyond replacing the dict, `repo_metadata` lets a repo declare itself **reproducible**. `helm_import_repository` already resolves a `sha256` for every fetch. A chart pinned by `sha256` is reproducible by definition, so we mark it `reproducible = True`. When no `sha256` was supplied we instead advertise the resolved one via `attrs_for_reproducibility`, exactly as the legacy bare-dict return did. The call is guarded with `hasattr`, matching the approach in bazel-contrib/rules_python#3597 and bazel-contrib/rules_multitool#123: `repo_metadata` was only added in Bazel 8.3.0, and this project still supports Bazel 7.x in CI. ## Testing Verified with `bazel fetch --repo=@... --force` on Bazel 9.1.0 against the charts in `tests/test_deps.bzl`: | Scenario | Result | |---|---| | `postgresql`/`grafana`/`redis` with `sha256` | `reproducible = True`, no DEBUG, fetch cached | | `postgresql` with `sha256` removed | DEBUG correctly suggests adding `sha256 = "..."`, fetch succeeds |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue
helm_import_repository's implementation returns the dict Bazel treats as the repository's "canonical reproducible form". Bazel compares each returned attribute against the declared one and emits aDEBUGmessage suggesting the user add any that differ.urlis mutually exclusive withrepository/chart_name/version(the rulefail()s if both are set), but the implementation returned all of them unconditionally. So the suggested form is one the rule itself rejects:url→ suggests addingchart_name/versionrepository→ suggests addingurlEither way the user gets a confusing, unactionable
DEBUGmessage. Fixes #189.Change
Return only the attributes matching the source type actually used, so the suggested reproducible form is always a valid re-declaration:
urlmode →{name, url, sha256}repositorymode →{name, repository, chart_name, version, sha256}Testing
Verified with
bazel fetch --repo=@... --forceagainst the charts already intests/test_deps.bzl:postgresqlurl=(http)chart_name/versiongrafanaurl=(oci)chart_name/versionredisrepository=urlFixes #189