A common point of confusion I see around `run_binary` is that it's hard coded to only expand `$(location` values which in codebases I work in are otherwise completely eliminated due to it being described as "legacy"
> location: A synonym for either execpath or rootpath, depending on the attribute being expanded. This is legacy pre-Starlark behavior and not recommended unless you really know what it does for a particular rule. See [#2475](https://github.com/bazelbuild/bazel/issues/2475#issuecomment-339318016) for details.
If `execpath` is used instead as the appropriate alternative, the rule does no do any expansion and fails the action. This change adds support for expanding all available patterns whenever they're provided.
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.
This rule is an alternative for genrule(): it can
run a binary with the desired arguments,
environment, inputs, and outputs, as a single
build action, without shelling out to Bash.
Fixes https://github.com/bazelbuild/bazel-skylib/issues/149
UebelAndre