Bazel build targets dependent on v3 APIs from go-control-plane fail to build

[CelsoSantos]

Title: Bazel build targets dependent on v3 APIs from go-control-plane fail to build

Description:
I have a custom ext-authz server implementation that is dependant/imports envoy's go-control-plane module and that generates a custom jwt based of the information present on a given header.
On this server I have implementations for both of Envoy's v2 and v3 API.

Recently, due to the removal of zlib 1.2.11, I was forced to update my Bazel rules, Gazelle and Bazel versions.
At the same time I also updated my go modules to the latest available versions, including go-control-plane:

module github.com/celsosantos/edge-proxy

go 1.16

require (
	github.com/dgrijalva/jwt-go v3.2.0+incompatible
	github.com/envoyproxy/go-control-plane v0.10.1
	github.com/golang/protobuf v1.5.2
	github.com/lestrrat-go/jwx v1.0.5
	golang.org/x/net v0.0.0-20220403103023-749bd193bc2b // indirect
	golang.org/x/sys v0.0.0-20220403205710-6acee93ad0eb // indirect
	google.golang.org/genproto v0.0.0-20210226172003-ab064af71705
	google.golang.org/grpc v1.36.0
	google.golang.org/protobuf v1.28.0 // indirect
)

While targets that implement/depend on the v2 API are working and building just fine, any targets that are dependent on the v3 API are failing to build with the following message:

ERROR: /workspace/api/v3/BUILD.bazel:5:11: 
no such package '@com_github_envoyproxy_go_control_plane//envoy/service/auth/v3': 
BUILD file not found in directory 'envoy/service/auth/v3' of external repository @com_github_envoyproxy_go_control_plane. 
Add a BUILD file to a directory to mark it as a package. and referenced by '//api/v3:api'

I have a reproduction of the issue at CelsoSantos/edge-proxy as well as further information on the repo's README Issue #2

What is going on? Why would targets that implement the v2 API work just fine while the ones that depend on v3 implementation fail? I see the sources in the correct place, so I don't understand why this would break.

Did something change on Envoy's API or build that would trigger this issue?

Thanks

[alyssawilk]

cc @keith

[yanavlasov]

cc @kyessenov

[keith]

I don't know much about golang dep management, but based on the go.sum file in that repo I think you are somehow pointing at an old version of the go-control-plane repo. Here are the related entries:

github.com/envoyproxy/go-control-plane v0.9.0/go.mod h1:YTl/9mNaCwkRvm6d1a2C3ymFceY/DCBVvsKhRF0iEA4=
github.com/envoyproxy/go-control-plane v0.9.1-0.20191026205805-5f8ba28d4473/go.mod h1:YTl/9mNaCwkRvm6d1a2C3ymFceY/DCBVvsKhRF0iEA4=
github.com/envoyproxy/go-control-plane v0.9.4/go.mod h1:6rpuAdCZL397s3pYoYcLgu1mIlRU8Am5FuJP05cCM98=
github.com/envoyproxy/go-control-plane v0.9.9-0.20201210154907-fd9021fe5dad/go.mod h1:cXg6YxExXjJnVBQHBLXeUAgxn2UodCpnH306RInaBQk=
github.com/envoyproxy/go-control-plane v0.10.1 h1:cgDRLG7bs59Zd+apAWuzLQL95obVYAymNJek76W3mgw=
github.com/envoyproxy/go-control-plane v0.10.1/go.mod h1:AY7fTTXNdv/aJ2O5jwpxAPOWUZ7hQAEvzN5Pf27BkQQ=

I see that the v3 directory doesn't exist when I peek into bazel's internal checkout of that repo as well:

% ls bazel-out/../../../external/com_github_envoyproxy_go_control_plane/envoy/service/auth
v2      v2alpha v3alpha

even though it's clearly in the tag you're trying to specify https://github.com/envoyproxy/go-control-plane/tree/v0.10.1/envoy/service/auth

[keith]

Also if I look in bazel-out/../external/bazel_gazelle/deps.bzl I see the old version being loaded as well:

    _maybe(
        go_repository,
        name = "com_github_envoyproxy_go_control_plane",
        importpath = "github.com/envoyproxy/go-control-plane",
        sum = "h1:4cmBvAEBNJaGARUEs3/suWRyfyBfhf7I60WBZq+bv2w=",
        version = "v0.9.1-0.20191026205805-5f8ba28d4473",
    )

[CelsoSantos]

Well, somehow, somewhere, I managed to fix this. I think (though not 100% certain) that it was actually go mod tidy that was calling back previous versions of envoy (I don't know from where or why, though), so much so that they are still there and I can't remove them..

But this PR, fixes whatever issue was present before: CelsoSantos/edge-proxy#1.

I'm closing the issue.

Thank you everyone for the help, especially @keith which helped to guide a starting point for a fix/investigation into the issue.

[keith]

Glad you fixed it!