-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Support multiple remote execution digest functions #16791
Support multiple remote execution digest functions #16791
Conversation
8b62a48
to
cc9f8bb
Compare
The following PR on the remote-apis side adds support for remote execution services to announce support for multiple digest functions: bazelbuild/remote-apis#236 This makes migrating from one digest function to the other more graceful. This change extends Bazel's server capabilities checking code to take the new field in the execution capabilities into account.
cc9f8bb
to
ff4bb59
Compare
// Check execution digest function. The protocol only later added | ||
// support for multiple digest functions for remote execution, so | ||
// check both the singular and repeated field. | ||
if (execCap.getDigestFunctionsList().isEmpty() && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It misses a case where execCap.getDigestFunctionsList().isEmpty()
and execCap.getDigestFunction() == DigestFunction.Value.UNKNOWN
, it should print the UNKNOWN function, instead of empty list.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The question is, is this really what should be preferred? My interpretation is that digest_functions
(plural) is what's authoritative now, with digest_function
(singular) being a fallback. If both of them are unset, then I would assume it would make most sense to display an error message using the native format of digest_functions
(plural), which is a list.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, that make sense.
// Check execution digest function. The protocol only later added | ||
// support for multiple digest functions for remote execution, so | ||
// check both the singular and repeated field. | ||
if (execCap.getDigestFunctionsList().isEmpty() && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, that make sense.
Hi @coeuvre, Should i import third-party changes first for this PR or share internal CL ? |
I will import the third-party changes via another CL. |
The following PR on the remote-apis side adds support for remote execution services to announce support for multiple digest functions: bazelbuild/remote-apis#236 This makes migrating from one digest function to the other more graceful. This change extends Bazel's server capabilities checking code to take the new field in the execution capabilities into account. Partial commit for third_party/*, see #16791. Signed-off-by: Sunil Gowroji <sgowroji@google.com>
Third Party changes are merged at d0cba55 |
The following PR on the remote-apis side adds support for remote execution services to announce support for multiple digest functions: bazelbuild/remote-apis#236 This makes migrating from one digest function to the other more graceful. This change extends Bazel's server capabilities checking code to take the new field in the execution capabilities into account. Partial commit for third_party/*, see bazelbuild#16791. Signed-off-by: Sunil Gowroji <sgowroji@google.com>
The following PR on the remote-apis side adds support for remote execution services to announce support for multiple digest functions: bazelbuild/remote-apis#236 This makes migrating from one digest function to the other more graceful. This change extends Bazel's server capabilities checking code to take the new field in the execution capabilities into account. Closes bazelbuild#16791. PiperOrigin-RevId: 517084447 Change-Id: I72afce6c1fae9e624f9e7ed1936c744ae9c81280
* Support multiple remote execution digest functions The following PR on the remote-apis side adds support for remote execution services to announce support for multiple digest functions: bazelbuild/remote-apis#236 This makes migrating from one digest function to the other more graceful. This change extends Bazel's server capabilities checking code to take the new field in the execution capabilities into account. Partial commit for third_party/*, see #16791. Signed-off-by: Sunil Gowroji <sgowroji@google.com> (cherry picked from commit d0cba55) * Support multiple remote execution digest functions The following PR on the remote-apis side adds support for remote execution services to announce support for multiple digest functions: bazelbuild/remote-apis#236 This makes migrating from one digest function to the other more graceful. This change extends Bazel's server capabilities checking code to take the new field in the execution capabilities into account. Closes #16791. PiperOrigin-RevId: 517084447 Change-Id: I72afce6c1fae9e624f9e7ed1936c744ae9c81280 (cherry picked from commit f8c8875) --------- Co-authored-by: Ed Schouten <eschouten@apple.com>
The changes in this PR have been included in Bazel 6.4.0 RC1. Please test out the release candidate and report any issues as soon as possible. If you're using Bazelisk, you can point to the latest RC by setting USE_BAZEL_VERSION=last_rc. |
The following PR on the remote-apis side adds support for remote execution services to announce support for multiple digest functions:
bazelbuild/remote-apis#236
This makes migrating from one digest function to the other more graceful. This change extends Bazel's server capabilities checking code to take the new field in the execution capabilities into account.