Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

incompatible_remote_build_event_upload_respect_no_cache #15150

Closed
coeuvre opened this issue Mar 30, 2022 · 6 comments
Closed

incompatible_remote_build_event_upload_respect_no_cache #15150

coeuvre opened this issue Mar 30, 2022 · 6 comments
Assignees
Labels
incompatible-change Incompatible/breaking change P2 We'll consider working on this in future. (Assignee optional) team-Remote-Exec Issues and PRs for the Execution (Remote) team type: bug

Comments

@coeuvre
Copy link
Member

coeuvre commented Mar 30, 2022

Background

If remote cache is enabled, Bazel will upload blobs referenced in the BEP to remote cache and replace the file path in the BEP with URI pointing to the remote CAS so that consumers of BEP can find the blobs.

Problem

In some cases, we don't want to upload some blobs to remote cache by using tags (e.g. no-remote-cache-upload) or flags (e.g. --remote_upload_local_results=false). But the BEP file uploader ignores those flags and always upload blobs referenced in the BEP to remote cache even if the generating actions cannot be cached.

--incompatible_remote_build_event_upload_respect_no_cache was introduced by #14338 to fix this problem so that if the generating actions cannot be cached, their outputs won't be uploaded to remote cache by BEP.

Migration

If you don't use remote cache nor BEP, no migration is needed.

If you use tags or flags to prevent outputs being uploaded to remote cache, after the flag --incompatible_remote_build_event_upload_respect_no_cache is flipped, those blobs will not be uploaded to remote cache by BEP.

Expected timeline

We expect to flip --incompatible_remote_build_event_upload_respect_no_cache to true and remove it in Bazel 6.0.

@coeuvre coeuvre added P2 We'll consider working on this in future. (Assignee optional) incompatible-change Incompatible/breaking change team-Remote-Exec Issues and PRs for the Execution (Remote) team breaking-change-6.0 labels Mar 30, 2022
@coeuvre coeuvre self-assigned this Mar 30, 2022
@meteorcloudy meteorcloudy added migration-ready Incompatible flag is ready for migration with Bazel rolling releases or Bazel@last_green breaking-change-6.0 Incompatible flags to be flipped in Bazel 6.0 labels Aug 30, 2022
@meteorcloudy
Copy link
Member

@coeuvre Should we flip this flag now?
https://buildkite.com/bazel/bazelisk-plus-incompatible-flags/builds/1253 says it won't break any downstream projects (ignore the rules_nodejs ones)

@coeuvre
Copy link
Member Author

coeuvre commented Sep 15, 2022

I am not confident enough to flip this flag for 6.0, especially considering there are some edge cases this flag cannot solve (#16151). I might work in another direction to solve the problem which could allow us to remove this flag. I'm not clear ATM.

@coeuvre coeuvre removed migration-ready Incompatible flag is ready for migration with Bazel rolling releases or Bazel@last_green breaking-change-6.0 Incompatible flags to be flipped in Bazel 6.0 labels Sep 15, 2022
@brentleyjones
Copy link
Contributor

This was deprecated in 6.0. @coeuvre I'm going to make a PR that makes it a no-op for 7.0, so it can be fully removed in 8.0, okay?

@coeuvre
Copy link
Member Author

coeuvre commented Apr 5, 2023

SGTM. Thanks!

@brentleyjones
Copy link
Contributor

#17989

@coeuvre
Copy link
Member Author

coeuvre commented Oct 20, 2023

Already flipped. Closing.

@coeuvre coeuvre closed this as completed Oct 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
incompatible-change Incompatible/breaking change P2 We'll consider working on this in future. (Assignee optional) team-Remote-Exec Issues and PRs for the Execution (Remote) team type: bug
Projects
None yet
Development

No branches or pull requests

4 participants