Making this repository play nicely with Bazel

[munnerz]

I've been trying to manage my application with Bazel, to make testing, building, running and deploying easier.

I have run into a few issues however with this repository (which is vendored into my own). These may be considered to be bazel issues, however some may be fixable on this side 😄

Namely, the issues I've hit:

• You symlink ./cmd/etcd->../, which creates an infinitely long path, which Bazel will not deal well with.
• A number of bash scripts are named 'build' - I am using OSX, which has a case insensitive filesystem (which I hate, but alas) - this causes Bazel to attempt to parse these files as bazel BUILD files, again causing issues.

I'm not sure how much of this you'd be willing to address in your own repository, but have not noticed any other issues detailing the problems above on the repo so thought I'd open some discussion 😄

[xiang90]

We have no plan to support Bazel. But we are open to explore it.

I mark this as help wanted. I want to know the benefits of adding the support of Bazel, the cost of maintaining the support, and the potential drawback of it before we can make the decision.

Thanks.

[gyuho]

@xiang90 We don't need symlinks anymore (was introduced from #4913), now that etcd requires Go 1.9+.

[ixdy]

@munnerz naming the Bazel build files BUILD.bazel instead of BUILD should fix the case-insensitivity issue - it's what we did for the root build file in kubernetes/kubernetes (where there is a conflicting build/ directory).

[gyuho]

@munnerz I've noticed upgrading to Go 1.10 noticeably speeds up our build time.
Is there any other benefit of using Bazel, other than build cache?

[gyuho]

As @ixdy mentioned, renaming seems to resolve your issue. And we've removed symlinks.
I don't think anything is blocking from supporting bazel for external projects.

Please reopen if there are still issues.

[cceckman]

Leaving a breadcrumb here in case it helps someone else: the default configuration for Bazel doesn't play nice with this repo, but there's one small tweak that does make it work.

With the client library imported into a Bazel project using go_repository, I got this error:

ERROR: /home/cceckman/.cache/bazel/_bazel_cceckman/f1b50997062ccc9720bca7431856fadc/external/com_github_coreos_etcd/mvcc/mvccpb/BU
ILD.bazel:11:1: no such package '@com_github_coreos_etcd//gogoproto': BUILD file not found on package path and referenced by '@com
_github_coreos_etcd//mvcc/mvccpb:mvccpb_go_proto'

Bazel knows how to generate .pb.go sources, generally, but it looks like it was trying to generate them on top of the .pb.go files- which didn't work with the relative imports of gogoproto in the proto files.

go_repository has a build_file_proto_mode flag which specifies whether or not to generate the .pb.go files. Setting it to disabled fixed the build for me.

W/rt "other benefit[s] of using Bazel" - Bazel has a very strong emphasis on reproduceability and hermeticity, which the go tool itself doesn't provide. Vendoring (via go_repository or whatnot) is effectively required; it's pretty well guaranteed that a build isn't picking up any packages from the local GOPATH. May not be to everyone's taste, but I do like that property. :-)

[ixdy]

One more breadcrumb: by default, gazelle prefers BUILD.bazel over BUILD, but it'll use the latter if a file by that name already exists.

On macOS, it's probably treating the build file as a BUILD file, and so gazelle fails to do the right thing by default.

Passing -build_file_name BUILD.bazel should make gazelle work properly with the etcd repo.