[remote] Respect whether the server supports action cache updates #16624
Conversation
This file contains 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
Only a subset of users may be allowed to update the action cache
(e.g., only CI but not devs).
Today, there are 2 ways to achive the desired behavior:
- `GetCapabilities` returning that all users are allowed to update,
and `UpdateActionResult` returning an error that Bazel prints and
ignores, or
- have the users that are not allowed to update the action cache
set `--remote_upload_local_results=false`.
Why don't we instead respect whether the remote cache supports
uploading action results?
Note that this requires support from the remote system to fully work
(i.e., it needs to return `update_enabled = false` for users that
don't have permission). Otherwise, Bazel's behavior will be the
same as before this change: failed `UpdateActionResult` do not cause
the build to fail. The only change this introduces is that Bazel
will no longer error if `--remote_upload_local_results=true`
and `GetCapabilities` returning `update_enabled = false`.
|
@Yannic what do you think about printing an info- or warning-level message if remote_upload_local_results=true but the server returns update_enabled=false? Maybe something like "INFO: remote cache has disabled action result uploads, so --remote_upload_local_results setting will be ignored." Asking because users might be confused by action uploads silently not working, especially if they are intentionally passing --remote_upload_local_results at the command line (though I understand the messaging might be considered "noise" if users don't care whether their results are uploaded or not). "Why wasn't |
sgowroji
added
the
team-Remote-Exec
|
@bduffany That sounds reasonable, at least for a transition period. It's also known server-side, so it would be possible to add a warning server-side for that (e.g., on the result page). |
This reverts commit d63c5c8.
|
@bazel-io flag |
bazel-io
added
the
potential release blocker
|
I'd like to get this into 6.0.0 if at all possible |
coeuvre
approved these changes
Nov 8, 2022
coeuvre
added
the
awaiting-PR-merge
sgowroji
removed
the
awaiting-PR-merge
Yannic
added a commit
to EngFlow/bazel
that referenced
this pull request
Nov 9, 2022
…ates Only a subset of users may be allowed to update the action cache (e.g., only CI but not devs). Today, there are 2 ways to achive the desired behavior: - `GetCapabilities` returning that all users are allowed to update, and `UpdateActionResult` returning an error that Bazel prints and ignores, or - have the users that are not allowed to update the action cache set `--remote_upload_local_results=false`. Why don't we instead respect whether the remote cache supports uploading action results? Note that this requires support from the remote system to fully work (i.e., it needs to return `update_enabled = false` for users that don't have permission). Otherwise, Bazel's behavior will be the same as before this change: failed `UpdateActionResult` do not cause the build to fail. The only change this introduces is that Bazel will no longer error if `--remote_upload_local_results=true` and `GetCapabilities` returning `update_enabled = false`. Closes bazelbuild#16624. PiperOrigin-RevId: 486901751 Change-Id: I0991f6891e21711df1e23ae0998a8bc95e2389bc
meteorcloudy
pushed a commit
that referenced
this pull request
Nov 10, 2022
…ates (#16724) Only a subset of users may be allowed to update the action cache (e.g., only CI but not devs). Today, there are 2 ways to achive the desired behavior: - `GetCapabilities` returning that all users are allowed to update, and `UpdateActionResult` returning an error that Bazel prints and ignores, or - have the users that are not allowed to update the action cache set `--remote_upload_local_results=false`. Why don't we instead respect whether the remote cache supports uploading action results? Note that this requires support from the remote system to fully work (i.e., it needs to return `update_enabled = false` for users that don't have permission). Otherwise, Bazel's behavior will be the same as before this change: failed `UpdateActionResult` do not cause the build to fail. The only change this introduces is that Bazel will no longer error if `--remote_upload_local_results=true` and `GetCapabilities` returning `update_enabled = false`. Closes #16624. PiperOrigin-RevId: 486901751 Change-Id: I0991f6891e21711df1e23ae0998a8bc95e2389bc
meteorcloudy
removed
the
potential release blocker
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Only a subset of users may be allowed to update the action cache (e.g., only CI but not devs).
Today, there are 2 ways to achive the desired behavior:
GetCapabilitiesreturning that all users are allowed to update, andUpdateActionResultreturning an error that Bazel prints and ignores, or--remote_upload_local_results=false.Why don't we instead respect whether the remote cache supports uploading action results?
Note that this requires support from the remote system to fully work (i.e., it needs to return
update_enabled = falsefor users that don't have permission). Otherwise, Bazel's behavior will be the same as before this change: failedUpdateActionResultdo not cause the build to fail. The only change this introduces is that Bazel will no longer error if--remote_upload_local_results=trueandGetCapabilitiesreturningupdate_enabled = false.