Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

--experimental_remote_repo_contents_cache#27509

fmeum started this conversation inGeneral
Nov 3, 2025· 2 comments· 6 replies
Discussion options

fmeum
Nov 3, 2025
Collaborator

Use this discussion to provide feedback on the new remote repository cache introduced in Bazel 9 as an experimental feature.

FAQs

How do I enable the remote repo contents cache?

  • Enable the--experimental_remote_repo_contents_cachestartup flag.
  • Use any remote cache (both HTTP and gRPC are supported) via--remote_cache or--remote_executor.

Which repo rules are supported?

  • A repository rule has to returnrepository_ctx.repo_metadata(reproducible = True) to be eligible for caching.
  • As a further limitation of the current experimental implementation, only repo rules without any dependencies added at runtime (e.g., viarepository_ctx.watch or.getenv) are supported. We hope to lift this restriction in the future. You can check a repo with canonical name@@<repo_name> for runtime deps by opening the file$(bazel info output_base)/external/@<repo_name>.marker - all lines after the first one are runtime deps.
You must be logged in to vote

Replies: 2 comments 6 replies

Comment options

keith
Nov 3, 2025
Collaborator

As a starting point I have 2 initial questions:

  • do we need to worry about anything on the remote exec service side that needs to be added for this?
  • is there an easy way to spot out repository_rules that have thewatch /getenv requirements that maybe don't need them so we could change them to be compatible with this?
You must be logged in to vote
1 reply
@fmeum
Comment options

fmeumNov 4, 2025
Collaborator Author

I started an FAQ list with answers to these questions.

Comment options

The commit message contains this:

Repositories are cached in a regular remote cache as AC entries

Do I interpret this correctly to mean that I need to allow Bazel to write to the remote AC directly?
I think many companies only allow the remote executor to set AC entries for the remote cache to avoid attackers poisoning the remote action cache.

Since repository rules still run locally (unless they are cached), this design makes a lot of sense.
Just trying to get confirmation.

You must be logged in to vote
5 replies
@fmeum
Comment options

fmeumNov 5, 2025
Collaborator Author

That is correct. My general assumption has been that you would allow CI machines to write AC entries and those would then also be able to populate the remote repo contents. Devs could then consume those just fine. Are you really referring to a setup in which Bazel itself never writes AC entries but remote executors do so directly?

@malt3
Comment options

Are you really referring to a setup in which Bazel itself never writes AC entries but remote executors do so directly?

Yes that's precisely correct. I believe BuildBuddy and BuildBarn support this configuration.

@malt3
Comment options

I think the feature is still great and I'll enable it in most environments, but I think it's important to point out what it entails.

@fmeum
Comment options

fmeumNov 5, 2025
Collaborator Author

This would be difficult to support since it's completely unclear how to remotely execute (even a reproducible) repo rule - this would essentially require turning Bazel into a standalone Starlark interpreter of sorts. I guess at that point it would be easier to set up a trusted "repo rule evaluation" machine running regular Bazel?

@malt3
Comment options

Yes, sorry. I think we are talking about different things.
I was merely saying that it's a common setup to prevent writes to the AC from Bazel.
I agree that it's extremely hard to work around that limitation.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Category
General
Labels
None yet
3 participants
@fmeum@keith@malt3

[8]ページ先頭

©2009-2025 Movatter.jp