envoy
envoy copied to clipboard
[WIP] deps: Bump `proxy_wasm_rust_sdk` -> 0.2.2
Created by Envoy dependency bot for @phlax
Fix #35321
also update rules_rust -> 0.48.0
Fix #35291
Signed-off-by: dependency-envoy[bot] <148525496+dependency-envoy[bot]@users.noreply.github.com>
CC @envoyproxy/dependency-shepherds: Your approval is needed for changes made to (bazel/.*repos.*\.bzl)|(bazel/dependency_imports\.bzl)|(api/bazel/.*\.bzl)|(.*/requirements\.txt)|(.*\.patch).
envoyproxy/dependency-shepherds assignee is @phlax
cc @mpwarres @martijneken updating these deps is still blocked by proxy-wasm-cpp-host needing an update (and conversion to crate_universe etc)
/wait
@phlax is it still blocked?
is it still blocked?
yeah, i believe so
Hi. I'm working on the crate_universe issue, I think that's close to being fixed. @mpwarres is back from OOO this week and will be looking at the macOS issue.
Can you clarify which parts are blocking the rust SDK, and whether these CI issues will actually unblock you? I don't know how they are related.
so this is the error
ERROR: /build/bazel_root/base/external/proxy_wasm_cpp_host/bazel/cargo/wasmtime/BUILD.bazel:42:6: error loading package '@wasmtime__wasmtime__9_0_3//': cannot load '@rules_rust//cargo:cargo_build_script.bzl': no such file and referenced by '@proxy_wasm_cpp_host//bazel/cargo/wasmtime:wasmtime'
ERROR: Evaluation of query "deps((//contrib/exe/... union //distribution/... union //source/exe/... union @com_github_google_quiche//:ci_tests union @nodejs//... union //test/...))" failed: preloading transitive closure failed: error loading package '@wasmtime__wasmtime__9_0_3//': cannot load '@rules_rust//cargo:cargo_build_script.bzl': no such file
Fetch failed
i went down the rabbit hole a little last week and came to the conclusion that we needed to update rules_rust to update proxy_wasm_rust_sdk - i tried to do that here (in this PR) and hit above issue
i looked at the changes in the rules_rust repo and (cant rem exactly why) came to the conclusion we need to update cpp-host first
needed to update rules_rust to update proxy_wasm_rust_sdk
Ahh gotcha, I'll look at that in CppHost too then.
CppHost CI is fixed, rules_rust to be updated in https://github.com/proxy-wasm/proxy-wasm-cpp-host/pull/406.
brilliant, thanks @martijneken - ill have a go again at bumping this batch of deps
@martijneken thanks - confirming that cpp_host has now been updated
unfortunately this still fails due to https://github.com/bazelbuild/rules_rust/issues/2665
cf: https://dev.azure.com/cncf/envoy/_build/results?buildId=178626&view=logs&j=b6a93b2f-c9eb-5004-2b80-f11f3e41d6df&t=b9aeef91-fdf0-5be6-08f0-d544c00fc771&l=276
unfortunately this still fails due to bazelbuild/rules_rust#2665
Seems like we ran into this on the ProxyWasmCppHost side too, and decided to use rules_rust 0.42 for now: https://github.com/proxy-wasm/proxy-wasm-cpp-host/blob/f199214a43337e115469d9f0dd6b77858746441b/bazel/repositories.bzl#L93-L103
Can we do the same here?
Can we do the same here?
most likely, ill try it now ...
seems not out of the box - afaict its failing due to:
https://github.com/proxy-wasm/proxy-wasm-rust-sdk/blob/3f4274ec8c6276cb187eb2c3a76752cb915b9c01/bazel/cargo/remote/BUILD.ahash-0.8.11.bazel#L208
which i think is most likely related to the rules_rust version which is higher in rust-sdk
unfortunately this still fails due to bazelbuild/rules_rust#2665
Seems like we ran into this on the ProxyWasmCppHost side too, and decided to use rules_rust 0.42 for now: https://github.com/proxy-wasm/proxy-wasm-cpp-host/blob/f199214a43337e115469d9f0dd6b77858746441b/bazel/repositories.bzl#L93-L103
Can we do the same here?
Hi @phlax and @martijneken ,
just a drive-by comment. I was working on a personal project and was able to update rules_rust in envoy to the latest version that has pkg_name attribute already. To work around the issue in https://github.com/bazelbuild/rules_rust/issues/2665 I added this to the .bazelrc:
build --incompatible_merge_fixed_and_default_shell_env
Patching rules_rust also worked, but just setting incompatible_merge_fixed_and_default_shell_env to the value that became default in later bazel versions seemed like a better approach.
Maybe you can give that a try?
brilliant! huge thanks @krinkinmu - ill give it a whirl