bazel: build failure when using envoy as an external repository

[bplotnick]

Title: bazel: build failure when using envoy as an external repository

Description:
When using envoy as an external repository such as in envoy-filter-example, building @envoy//source/... fails

It looks like crates_repository is somehow looking for the lockfiles in the root repository rather than within the @envoy repository. CC: @mathetake

Notably, building the main application (bazel build @envoy//source/exe:envoy) does not seem to fail.

Repro steps:

git clone https://github.com/envoyproxy/envoy-filter-example.git
cd envoy-filter-example
git submodule --update
sed -i 's/{ENVOY_SRCDIR}/envoy/' WORKSPACE
bazel build @envoy//source/...

The output is

IINFO: Repository dynamic_modules_rust_sdk_crate_index instantiated at:
  /home/envoybuild/envoy-filter-example/WORKSPACE:30:25: in <toplevel>
  /home/envoybuild/.cache/bazel/_bazel_envoybuild/405525df6bbb4394babec7266af37f69/external/envoy/bazel/dependency_imports.bzl:61:24: in envoy_dependency_imports
  /home/envoybuild/.cache/bazel/_bazel_envoybuild/405525df6bbb4394babec7266af37f69/external/envoy/bazel/dependency_imports.bzl:212:22: in crates_repositories
Repository rule crates_repository defined at:
  /home/envoybuild/.cache/bazel/_bazel_envoybuild/405525df6bbb4394babec7266af37f69/external/rules_rust/crate_universe/private/crates_repository.bzl:124:36: in <toplevel>
INFO: repository @@dynamic_modules_rust_sdk_crate_index' used the following cache hits instead of downloading the corresponding file.
 * Hash '53418ae5457040e84009f7c69b070e1f12f10a9a3a3ef4f5d0829c66e5438ba1' for https://github.com/bazelbuild/rules_rust/releases/download/0.56.0/cargo-bazel-x86_64-unknown-linux-gnu
If the definition of 'repository @@dynamic_modules_rust_sdk_crate_index' was updated, verify that the hashes were also updated.
ERROR: /home/envoybuild/.cache/bazel/_bazel_envoybuild/405525df6bbb4394babec7266af37f69/external/rules_rust/crate_universe/private/generate_utils.bzl:335:36: An error occurred during the fetch of repository 'dynamic_modules_rust_sdk_crate_index':
   Traceback (most recent call last):
        File "/home/envoybuild/.cache/bazel/_bazel_envoybuild/405525df6bbb4394babec7266af37f69/external/rules_rust/crate_universe/private/crates_repository.bzl", line 34, column 30, in _crates_repository_impl
                lockfiles = get_lockfiles(repository_ctx)
        File "/home/envoybuild/.cache/bazel/_bazel_envoybuild/405525df6bbb4394babec7266af37f69/external/rules_rust/crate_universe/private/generate_utils.bzl", line 335, column 36, in get_lockfiles
                cargo = repository_ctx.path(repository_ctx.attr.cargo_lockfile),
Error in path: Unable to load package for //source/extensions/dynamic_modules/sdk/rust:Cargo.lock: BUILD file not found in any of the following directories. Add a BUILD file to a directory to mark it as a package.
 - /home/envoybuild/envoy-filter-example/source/extensions/dynamic_modules/sdk/rust
WARNING: Target pattern parsing failed.
ERROR: Skipping '@envoy//source/...': error loading package under directory 'source': no such package '@@dynamic_modules_rust_sdk_crate_index//': Unable to load package for //source/extensions/dynamic_modules/sdk/rust:Cargo.lock: BUILD file not found in any of the following directories. Add a BUILD file to a directory to mark it as a package.
 - /home/envoybuild/envoy-filter-example/source/extensions/dynamic_modules/sdk/rust
ERROR: error loading package under directory 'source': no such package '@@dynamic_modules_rust_sdk_crate_index//': Unable to load package for //source/extensions/dynamic_modules/sdk/rust:Cargo.lock: BUILD file not found in any of the following directories. Add a BUILD file to a directory to mark it as a package.
 - /home/envoybuild/envoy-filter-example/source/extensions/dynamic_modules/sdk/rust
INFO: Elapsed time: 0.229s
INFO: 0 processes.
ERROR: Build did NOT complete successfully

[mathetake]

So so two points to make...

First of all, i think my question for @phlax is how much effort do we want to make to keep the downstream Envoy custom build possible. If that's must-have, we need to fix envoyproxy/envoy-filter-example which has been broken more than 4 years and no one has any intention to fix at the moment (@phlax and I chatted about even we should archive the repo, etc), or at least
we should have another CI step verify that the fork custom build is possible.

The other one is that I think rules_rust has been such a trouble maker for a very long time like #38314, and we should rethink about the setup of the toolchain...

[phlax]

wrt envoy-filter-example - im open to keeping it around - my ~intention was to add it to the examples repo, so it would be tested/documented alongside the other examples - but it requires a bit to setup and is heavy (kinda requires our build container atm)

rules_rust - argh - im just battling with that right now - each version seems to be broken in its own unique and subtle ways - tracking down the issues is non-trivial - and fixing one often creates another

that said the above issue looks more like the WORKSPACE just not being setup correctly in sync with how envoys current WORKSPACE works

[bplotnick]

First of all, i think my question for @phlax is how much effort do we want to make to keep the downstream Envoy custom build possible. If that's must-have, we need to fix envoyproxy/envoy-filter-example which has been broken more than 4 years and no one has any intention to fix at the moment (@phlax and I chatted about even we should archive the repo, etc), or at least
we should have another CI step verify that the fork custom build is possible.

What's the alternative to a custom build if you have static filters? We certainly have an interest in ensuring that the build continues to work as this is how we build the proxy. The building of @envoy//source/exe:envoy_main_entry_lib does work, which means that people's custom builds are still working. It's just that other build commands (for example generating the compdb) do not. This is why I suspect that other people have not noticed.

[bplotnick]

as another point of comparison. this repros on https://github.com/istio/proxy

[mathetake]

The building of @envoy//source/exe:envoy_main_entry_lib does work, which means that people's custom builds are still working. It's just that other build commands (for example generating the compdb) do not.

i see...

[mathetake]

i think i got the fix anyways

[mathetake]

#38957 i believe at least this closes this issue