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
Creates MODULE.bazel and WORKSPACE.bzlmod files to enable bazel-skylib
to work with the `--experimental_enable_bzlmod` flag.
rules_go has been updated as the previously used version is not
available in the BCR.
stardoc has been updated due to a strange issue with Bzlmod enabled that
caused the `diff_test` and `unittest` docs to be generated without any
contents that was magically fixed upon updating.
bazelbuild/bazel-central-registry#124
Co-authored-by: Alexandre Rostovtsev <arostovtsev@google.com>
See https://github.com/bazelbuild/bazel-federation/pull/127
In particular, this allows us to use a modern Stardoc release to fix generated md docs.
And we can remove internal_deps.bzl/internal_setup.bzl - it's unnecessary complexity
needed only for deprecated Federation setup.
- while the federation code is in flux, this will mean less churn for skylib
- rules_pkg is only needed by developers for making a distribution, so this won't impact users.
- when we develop a new federation model, we can re-depend the right way.
* Comply with the standards of the Bazel federation
This commit allows bazel_skylib to be a member of the Bazel federation, since it adds the required bzl files related to setup and dependencies.
Moreover, it also changes the WORKSPACE to fetch all dependencies through the federation.
* Add copyright and docstring to bzl files
- Update to newer version of stardoc.
- Make lib/selects.bzl stardoc compatible. There must be a block description before Args:
Docs now generate with
bazel build --incompatible_remap_main_repo docs:*
See https://github.com/bazelbuild/bazel/issues/7130 for reasons.
In this commit:
- change unittest.bzl to declare a named output
file instead of relying on the deprecated [1]
default output name (ctx.outputs.executable).
- define a new toolchain_type and toolchain rules
for cmd.exe and for Bash (basically Windows and
non-Windows)
- register the new toolchains in workspace.bzl
- let unittest.make-created test rules require the
new toolchain_type
- write the test output script as a Windows batch
script or as a Shell script, depending on the
selected toolchain
This PR enables the Bazel team to break the Bash
dependency (for test execution) on Windows, and
can run Starlark unittests with the new,
Windows-native test wrapper (still under
development).
See https://github.com/bazelbuild/bazel/issues/5508
Alexandre Rostovtsev