Documentation/guidance on releasing version of repository compatible with "go build"

[gonzojive]

What version of rules_go are you using?

v0.23.3

What version of gazelle are you using?

v0.21.1

What version of Bazel are you using?

Build label: 3.1.0
Build target: bazel-out/k8-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Wed Apr 22 10:32:27 2020 (1587551547)
Build timestamp: 1587551547
Build timestamp as int: 1587551547

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

Yes

What operating system and processor architecture are you using?

Ubuntu / AMD64

Any other potentially useful information about your toolchain?

Using gopls and VS Code, which do not yet support Bazel.

What did you do?

I have a little project that builds with bazel and includes .proto files (proto dir here). I would like the project to build using standard Go tools as well.

What did you expect to see?

Conventions or tools for publishing a bazel-based Go repository so that it builds with the standard go toolchain.

For projects that respect conventions (like one package per directory), it would be nice if rules_go helped maintian a version of a repository that builds with standard Go tools. I don't expect this to work in general, but for simple projects that are purely .go and .proto files it would be nice.

What did you see instead?

I think I will end up writing custom genrules for my project to do this.

[jayconrod]

What did you have in mind exactly? There are a few different ways this could be done. The main thing is that generated files (.pb.go, etc.) need to be checked in. They don't necessarily need to be checked in on the main development branch; just at released with semver tags.

If you're using go_proto_library, you can copy those files out of bazel-out or use something like go_path.

Alternatively, you can disable proto rule generation, run protoc separately (without Bazel), and build generated .pb.go files together with others with go_library.

[gonzojive]

Thanks. I'm not sure what's best exactly. If there were a tool (sort of like gazelle) for managing the release of a repository, I would use it. I'm not sure if you would want to include such a tool in rules_go or not.

I had not considered that the .pb.go files can be checked in only at semver tags. That's a scheme worth considering. It might be a little weird for someone to check out v1.0.0, edit some files, then realize that the main branch is missing the pb.go files. Maybe that doesn't matter.

Here is what I came up with - to at least generate the .pb.go files with a single command. If this were extended to also run a few git commands (commit the generated files and then git tag xxx the repository, I guess), it would be good enough for me. Even checking in the generated files all the time isn't the worst if they are maintained by a tool.