Support multiple remote execution digest functions#16791
Support multiple remote execution digest functions#16791EdSchouten wants to merge 1 commit intobazelbuild:masterfrom
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.
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.
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.
| // 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() && |
|
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.