Skip to content

feat: adopt repository_ctx.repo_metadata for Bazel 9#286

Merged
abrisco merged 3 commits into
periareon:mainfrom
ifutivic:feat/repo-metadata-bazel9
Jun 3, 2026
Merged

feat: adopt repository_ctx.repo_metadata for Bazel 9#286
abrisco merged 3 commits into
periareon:mainfrom
ifutivic:feat/repo-metadata-bazel9

Conversation

@ifutivic

@ifutivic ifutivic commented Jun 3, 2026

Copy link
Copy Markdown
Contributor

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

ifutivic added 2 commits June 3, 2026 09:31
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
Bazel 9 deprecates returning a bare dict from a repository rule
implementation in favor of `repository_ctx.repo_metadata`, which lets a
repo additionally declare itself reproducible so Bazel can cache the
fetched contents across workspaces.

A chart pinned by `sha256` is reproducible: refetching with the same
attributes yields identical output. Mark those repos `reproducible =
True`; otherwise advertise the resolved `sha256` via
`attrs_for_reproducibility` so users can pin it.

`repo_metadata` was added in Bazel 8.3.0, so guard on its availability
with `hasattr` and fall back to the legacy bare-dict return on older
versions (the project still supports Bazel 7.x in CI).

@abrisco abrisco left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, thanks! Just needs a rebase 😄

@ifutivic

ifutivic commented Jun 3, 2026

Copy link
Copy Markdown
Contributor Author

Thanks for the review! The PR has been rebased.
I'd really appreciate a new release so we can remove our internal patches for this.

@abrisco abrisco merged commit 6fb93f9 into periareon:main Jun 3, 2026
13 checks passed
@ifutivic ifutivic deleted the feat/repo-metadata-bazel9 branch June 3, 2026 15:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants