* Fix location of MODULE.bazel in distro tarballs.
* Remove invalid paths from WORKSPACE files in distro tarballs
* The resulting tarballs should finally be distributable as 1.4.0 in BCR.
After #400, the gazelle plugin has been cleanly separated out into its own bazel workspace, which will soon finally allow us to mark it stable. But this means:
* we need to change our bazelci config to explicitly build and test it, since `bazel build //...` no longer includes the plugin;
* we need to add proper distribution rules for it;
* we need to update release instructions, since now we will have two distribution tarballs
* Add the gazelle plugin to the distribution
To avoid everyone needing to take a dep on `rules_go`, we
do the following:
1. Regular Bazel users need to load `bazel_skylib_gazelle_plugin_workspace`
and call that, and then `bazel_skylib_gazelle_plugin_setup`
2. `bzlmod` users need do nothing, but we now include the
`rules_go` dep in the `MODULE.bazel` shipped in the release.
This is fine, because `bzlmod` will lazily load
dependencies.
* Run buildifier
* Add docstring to `gazelle_setup.bzl`
* Move "internal only" marker
* Make @com_github_bazelbuild_buildtools visible in the deployed module
* Respond to review comments
* Move plugin to a nested workspace
* Run buildifier
* Restore the module declaration from `main`
* Bump versions of rules_go and gazelle used in the top-level module to match the ones in gazelle
* Respond to review comments and add gazelle to ignored directories so //... works as expected
* Add missing descriptor for stardoc
* Move gazelle hints into workspace files
* Move Gazelle extension to //gazelle/bzl and change package name
This fixes an issue with importing bazel-skylib into
google3. Currently, Glaze (internal Go build file generator) attempts
to generate a target (//gazelle:gazelle) that conflicts with one
that's already declared here.
I think the right solution is actually to move the package into a
subdirectory. In the future (bazelbuild/bazel-gazelle#5), Gazelle's Go
extension will generate target names similar to what Glaze does, so
the same conflict will happen in open source. I think it's also
logical to have a directory of packages in case more need to be added
in the future, and for the extension to have a package name matching
the language it works with.
This is an incompatible change, but the //gazelle directory isn't part
of a tagged release yet, so hopefully it won't break anyone.
* fix runfiles access in test
* Fix gazelle package names.
Co-authored-by: Jay Conrod <jayconrod@google.com>
Alexandre Rostovtsev