All actions which use tool or executable for which is not clear if it comes from a toolchain, must set a `toolchain` parameter ( migration of Automatic Exec Groups).
As we discussed internally, I've modified actions so that it's recognised that tools are not from the toolchain. Hence, there will not be an error which states `Couldn't identify if tools are from implicit dependencies or a toolchain. Please set the toolchain parameter. If you're not using a toolchain, set it to 'None'.`. Hence, no need for the toolchain parameter.
* 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
* Do not register a Go toolchain for ourselves
This module can be used as a transitive dep, and so we want to
avoid forcing users to futz with their SDKs.
* Add a small comment
* 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
`@bazel_tools` is tricky since it is effectively a part of the standard
library that can not have a `bzl_library` attached to it. As a simple
fix for this, `bzl_library` can have a srcs dependency on it so that it
includes the transitive closure of all of its dependencies.
`@bazel_tools` imports are rewritten into the `srcs` attribute since
they are `exports_files`ed from the @bazel_tools.
Co-authored-by: c-parsons <cparsons@google.com>
* 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>
kotlaja