no such target '@com_github_envoyproxy_protoc_gen_validate//validate:validate'

[derekperkins]

What version of rules_go are you using?

0.25.1

What version of gazelle are you using?

0.22.3

What version of Bazel are you using?

3.7 & 4.0

Does this issue reproduce with the latest releases of all the above?

Yes

What operating system and processor architecture are you using?

MacOS 11.1 Intel
Go 1.15.6

Any other potentially useful information about your toolchain?

## in BUILD
# gazelle:go_generate_proto false
# gazelle:proto disable_global


## in WORKSPACE
http_archive(
    name = "com_google_protobuf",
    sha256 = "d0f5f605d0d656007ce6c8b5a82df3037e1d8fe8b121ed42e536f569dec16113",
    strip_prefix = "protobuf-3.14.0",
    urls = [
        "https://mirror.bazel.build/github.com/protocolbuffers/protobuf/archive/v3.14.0.tar.gz",
        "https://github.com/protocolbuffers/protobuf/archive/v3.14.0.tar.gz",
    ],
)
load("@com_google_protobuf//:protobuf_deps.bzl", "protobuf_deps")

protobuf_deps()

## relevant entries from deps.bzl built by gazelle
    go_repository(
        name = "com_github_envoyproxy_go_control_plane",
        build_file_proto_mode = "disable_global",
        importpath = "github.com/envoyproxy/go-control-plane",
        sum = "h1:bbmjRkjmP0ZggMoahdNMmJFFnK7v5H+/j5niP5QH6bg=",
        version = "v0.9.8",
    )
    go_repository(
        name = "com_github_envoyproxy_protoc_gen_validate",
        build_file_proto_mode = "disable_global",
        importpath = "github.com/envoyproxy/protoc-gen-validate",
        sum = "h1:EQciDnbrYxy13PgWoY8AqoxGiPrpgBZ1R8UNe3ddc+A=",
        version = "v0.1.0",
    )
    go_repository(
        name = "com_github_cncf_udpa_go",
        build_file_proto_mode = "disable_global",
        importpath = "github.com/cncf/udpa/go",
        sum = "h1:inpz6arsmh6ys7jjP0G1noZqKcCPpV4GZmffBPilAjA=",
        version = "v0.0.0-20201211205326-cc1b757b3edd",
    )

What did you do?

I imported github.com/envoyproxy/go-control-plane to build an auth server for envoy

What did you expect to see?

Go builds just fine, but Bazel does not

What did you see instead?

ERROR: /external/com_github_cncf_udpa_go/udpa/annotations/BUILD.bazel:3:11: no such target '@com_github_envoyproxy_protoc_gen_validate//validate:validate': target 'validate' not declared in package 'validate' (did you mean 'validate.h'?) defined by /external/com_github_envoyproxy_protoc_gen_validate/validate/BUILD and referenced by '@com_github_cncf_udpa_go//udpa/annotations:annotations'
ERROR: /external/com_github_envoyproxy_go_control_plane/envoy/type/v3/BUILD.bazel:3:11: no such target '@com_github_envoyproxy_protoc_gen_validate//validate:validate': target 'validate' not declared in package 'validate' (did you mean 'validate.h'?) defined by /external/com_github_envoyproxy_protoc_gen_validate/validate/BUILD and referenced by '@com_github_envoyproxy_go_control_plane//envoy/type/v3:type'
ERROR: /external/com_github_cncf_udpa_go/xds/core/v3/BUILD.bazel:3:11: no such target '@com_github_envoyproxy_protoc_gen_validate//validate:validate': target 'validate' not declared in package 'validate' (did you mean 'validate.h'?) defined by /external/com_github_envoyproxy_protoc_gen_validate/validate/BUILD and referenced by '@com_github_cncf_udpa_go//xds/core/v3:core'
ERROR: /external/com_github_envoyproxy_go_control_plane/envoy/type/matcher/v3/BUILD.bazel:3:11: no such target '@com_github_envoyproxy_protoc_gen_validate//validate:validate': target 'validate' not declared in package 'validate' (did you mean 'validate.h'?) defined by /external/com_github_envoyproxy_protoc_gen_validate/validate/BUILD and referenced by '@com_github_envoyproxy_go_control_plane//envoy/type/matcher/v3:matcher'
ERROR: /external/com_github_envoyproxy_go_control_plane/envoy/config/core/v3/BUILD.bazel:3:11: no such target '@com_github_envoyproxy_protoc_gen_validate//validate:validate': target 'validate' not declared in package 'validate' (did you mean 'validate.h'?) defined by /external/com_github_envoyproxy_protoc_gen_validate/validate/BUILD and referenced by '@com_github_envoyproxy_go_control_plane//envoy/config/core/v3:core'
ERROR: /external/com_github_envoyproxy_go_control_plane/envoy/service/auth/v3/BUILD.bazel:3:11: no such target '@com_github_envoyproxy_protoc_gen_validate//validate:validate': target 'validate' not declared in package 'validate' (did you mean 'validate.h'?) defined by /external/com_github_envoyproxy_protoc_gen_validate/validate/BUILD and referenced by '@com_github_envoyproxy_go_control_plane//envoy/service/auth/v3:auth'

I hunted through all the references to protoc-gen-validate in rules_go / gazelle, of which there are quite a few. Adding protobuf as an http_archive link as per bazel-contrib/rules_go#2489 (comment) got me past a first batch of errors. In another issue, you suggested using tag/commit instead of version/sum in the go_repository, but that didn't seem to work.

It seems like protoc-gen-validate has caused a lot of heartache, so maybe there isn't an easy solution, but I'm not quite sure where to go from here. This is just a transitive dependency, so I'm happy to pin it or not load it as a go_repository or whatever might make this work.

[jayconrod]

I suspect you're running into #890, also described in #892 and #982.

Could you try setting build_file_naming_convention = "go-default_library" build_file_naming_convention = "go_default_library" on com_github_envoyproxy_protoc_gen_validate and any other repositories that have build files already?

[derekperkins]

Setting build_file_naming_convention = "go-default_library" didn't seem to affect anything. I also tried with build_file_generation = "off" as suggested in #892, but that didn't change the outcome.

github.com/cncf/udpa has build files, but github.com/cncf/udpa/go is declared as a separate module, and it does not contain any build files. Marking it as such gives this error

no such package '@com_github_cncf_udpa_go//udpa/annotations': BUILD file not found in directory 'udpa/annotations' of external repository @com_github_cncf_udpa_go. Add a BUILD file to a directory to mark it as a package. and referenced by '@com_github_envoyproxy_go_control_plane//envoy/type/v3:type'

[jayconrod]

Sorry to be slow to get back to this. build_file_naming_convention should be "go_default_library", not "go-default_library". Sorry for the typo... though I'm surprised nothing reported an error because of that.

Could you confirm whether there are build files in that repo and which naming convention is used? It would help narrow this down.

You can see Bazel's view of a repo by looking in a directory like $(bazel info output_base)/external/com_github_cncf_udpa_go. That's the directory produced by the repository rule for com_github_cncf_udpa_go. It should have build files either checked into the original Git repository or generated by Gazelle within go_repository.

build_file_naming_convention controls two things. First, it determines whether Gazelle targets have names like go_default_library or validate. By default in go_repository, Gazelle uses the import_alias convention, which generates targets with names like validate but also aliases named go_default_library so either name can be used. If the repository already has build files, they won't be modified though. So the second effect of build_file_naming_convention is to declare which naming convention is used for dependency resolution in other repositories. If a repository has checked in build files with names following the go_default_library convention, this tells Gazelle in other repositories to use those names.

[mtl-wgtwo]

FWIW, I have seen this problem as well. Setting build_file_naming_convention = "go_default_library" on com_github_envoyproxy_protoc_gen_validate did nothing for me.

The problem is here: https://github.com/envoyproxy/protoc-gen-validate/blob/main/validate/BUILD#L33-L38

go_proto_library(
    name = "go_default_library",
    importpath = "github.com/envoyproxy/protoc-gen-validate/validate",
    proto = ":validate_proto",
    visibility = ["//visibility:public"],
)

If I change this name to "validate" I can build properly.

[derekperkins]

@jayconrod No worries on the timing, I know you're super busy helping out lots of people. I think there might be another typo in that recommendation. That throws this error, no such attribute 'build_file_naming_convention' in 'go_repository' rule. If I switch to build_naming_convention like you mention here, #890 (comment), that error doesn't get thrown.

That doesn't eliminate the core issue however. I've tried all the combinations of these suggestions, including updating the library itself from v0.1.0 to v0.4.1. go build continues to succeed, but I can't get it to build with bazel. This is what I have now in deps.bzl

go_repository(
    name = "com_github_envoyproxy_protoc_gen_validate",
    build_file_generation = "off",
    build_file_proto_mode = "disable_global",
    build_naming_convention = "go_default_library",
    importpath = "github.com/envoyproxy/protoc-gen-validate",
    sum = "h1:7dLaJvASGRD7X49jSCSXXHwKPm0ZN9r9kJD+p+vS7dM=",
    version = "v0.4.1",
)

@mtl-wgtwo How are you making that change? Are you patching it with bazel? Would you mind sharing your config?

[derekperkins]

com_github_cncf_udpa_go appears to be using gazelle generated code

$(bazel info output_base)/external/com_github_cncf_udpa_go

$ cat WORKSPACE
# DO NOT EDIT: automatically generated WORKSPACE file for go_repository rule
workspace(name = "com_github_cncf_udpa_go")

com_envoyproxy_protoc_gen_validate seems to be picking up the build files from the repo.

$(bazel info output_base)/external/com_envoyproxy_protoc_gen_validate

$ cat WORKSPACE
workspace(name = "com_envoyproxy_protoc_gen_validate")

load("//bazel:repositories.bzl", "pgv_dependencies")

pgv_dependencies()

load("//bazel:dependency_imports.bzl", "pgv_dependency_imports")

pgv_dependency_imports()

load("//bazel:pip_dependencies.bzl", "pgv_pip_dependencies")

pgv_pip_dependencies()

load("//:dependencies.bzl", "go_third_party")

# gazelle:repository_macro dependencies.bzl%go_third_party
go_third_party()

[derekperkins]

I tried manually editing the BUILD file inside the private dir and changing the name from go_default_library to validate like @mtl-wgtwo suggested, I did get past this build issue and now am seeing this problem. bazel-contrib/rules_go#2206

Not sure if this is a tooling issue, or if there is a PR we might open upstream, or if we just need to settle for patching that file.

[mtl-wgtwo]

@derekperkins I suspect that we are both going through the same process -- I'm upgrading to the latest rules_go and stepping through the errors one at a time. I am still struggling with the multiple copies of package passed to linker errors as well.

Here's the patch I ended up with:

--- validate/BUILD.orig	2021-02-12 10:02:41.000000000 +0100
+++ validate/BUILD	2021-02-12 09:56:57.000000000 +0100
@@ -48,3 +48,9 @@
     visibility = ["//visibility:public"],
     deps = [":validate_proto"],
 )
+
+alias(
+    name = "validate",
+    actual = ":go_default_library",
+    visibility = ["//visibility:public"],
+)

and the go_repository rule:

    go_repository(
        name = "com_github_envoyproxy_protoc_gen_validate",
        build_file_proto_mode = "disable_global",
        importpath = "github.com/envoyproxy/protoc-gen-validate",
        sum = "h1:NVV8ILDiHugAAoCtGP7ERYoaumUffVMPQB2CV9C7jNs=",
        version = "v0.4.2-0.20201217164128-7df253a68e6b",
        patches = ["//3rd/golang:com_github_envoyproxy_protoc_gen_validate_validate_BUILD.patch"],
    )

[derekperkins]

Thanks for that. That alias clause seems pretty harmless compared to having to change the actual upstream name. Unless @jayconrod thinks it shouldn't be necessary, we should make a PR to add that to help others avoid this in the future.

Another thing that is confusing for me is that I had to add protobuf tooling to my WORKSPACE for this, even though all the generated pb.go files seem to be checked in and build_file_proto_mode is disabled. That's how we consume our internal protos and haven't needed the tooling before.

[derekperkins]

@jayconrod curious if you have any suggestions on a direction to try and resolve this

@mtl-wgtwo did you get through all the dependency issues?

[jayconrod]

Sorry, it looks like this still needs some debugging, but unfortunately I don't have bandwidth to look into it yet. I would have expected your go_repository declaration from this comment to work, so perhaps something is wrong inside Gazelle's dependency resolution.

[derekperkins]

I'm still seeing this with gazelle 0.23 and rules_go 0.27.0 and still haven't been able to get things to build.

Here are some related issues trying to get stable releases of these upstream dependencies.
cncf/xds#2
cncf/udpa#42
envoyproxy/go-control-plane#391

[fmeum]

I also ran into this error and can confirms it's fixed by bufbuild/protoc-gen-validate#471. Unfortunately, that requires specifying commit in the go_repository rule for com_github_envoyproxy_protoc_gen_validate.

[rfan-debug]

@fmeum Which commit should we specify for com_github_envoyproxy_protoc_gen_validate ?

[fmeum]

bufbuild/protoc-gen-validate@4f41f10 should work, but there have been releases since then you could use.

[derekperkins]

This works for us now, so I'll go ahead and close this issue