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.
While build settings allow for much cleaner flag and setting definitions
than `--define`, they have the major drawback that rules need to provide
dedicated support for them, which isn't the case for native and most
community-maintained rules.
This change attempts to bridge this gap by optionally exposing the value
of the common build setting types as Make variables to rules that depend
on them via the `toolchains` attribute: If the new `make_variable`
attribute is set, the value of the flag or setting is available as a
Make variable with that.
Consistency with pre-defined Make variables is enforced by limiting the
character set for `make_variable` values to `[A-Z0-9_]`. The new
attribute is also only added to int- and string-valued build settings as
the other types lack a canonical stringification.
Co-authored-by: Xùdōng Yáng <wyverald@gmail.com>
Required for Bazel 7 compatibility.
Note that rules_pkg 0.9.1 requires Python 3.6 or newer as the system's Python 3; this means we cannot build //distribution on Ubuntu 16.04 any more (which is fine, since it only affects the skylib developer workflow; users of skylib on Ubuntu 16.04 are not affected). Update CI config accordingly.
Fixes #414
I ran into an issue where I had a `build_test` that was only compatible with a particular platform. I had annotated the target with `target_compatible_with` but continued to get builds on the incompatible platform. This came down to my `bazel test //...` invocation picking up the `{name}_{idx}__deps` targets and building the dependency anyway. This change updates these targets to account for newer common attributes and tags them as manual so they're only built when the user facing test target is built.
In order to flip the flag, all downstream projects should be adapted. However, it is hard to fix them all if there are constant regressions. Adding it to the CI will ensure that once the project can build with incompatible_disallow_empty_glob it can keep building like that.
See: bazelbuild/bazel#15327
* 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
bazelbuild/bazel@6a8ddb7 changed the prefix for runfiles from the main
repo when Bzlmod is enabled. Because all uses of rlocation were
hardcoded to use "bazel_skylib", tests requiring runfiles stopped
working with Bzlmod enabled. This commit updates calls to rlocation to
instead use the TEST_WORKSPACE env var to get the repo name.
After some thought, I have to say that forcing a local strategy for
copy_file/copy_directory is inappropriate. The point of a sandbox is to
catch hermeticity bugs; disabling the sandbox may be useful for
performance, but it's up to the user to do it if they trust us - and
they can do it via flag. The default should be paranoia and safety.
And on the subject of strategies - using a genrule to create an empty
directory fails in environments where genrules run remote by default
(and thus, copy_directory tests fail). We could, of course, set local=1,
but that disables the sandbox and causes scary warnings. Instead, add a
proper empty_directory rule to test with.
Google internal linters are flagging skylib 1.3.0 because the stardoc_with_diff_test
macro lack a copyright notice and does not use a `name` parameter.
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>
copy_file currently includes the copied file in its runfiles even if it is not executable, which makes every rule depending on it have the file as a runfile (e.g. a `cc_library` depending on a copied header file via the hdrs attribute).
In an ideal world, according to https://docs.bazel.build/versions/main/skylark/rules.html#runfiles-features-to-avoid, `copy_file` would not need to specify any runfiles in the `DefaultInfo` it returns - specifying `files` should suffice. However, due to the existence of rules with legacy behavior, this would break compatibility (actually, already with `sh_test` in skylib's unit tests).
As a compromise that preserves compatibility with legacy rules but nevertheless cleans up the runfiles tree of depending rules, use the `data_runfiles` attribute of `DefaultInfo` if the copied file is not executable.
Followup to #330: remove the wrapper macro and export the rule directly; the macro
does not serve any useful function. As a side effect, this fixes the inability to
set tags etc., since the macro did not support **kwargs.
This attribute is incorrectly being built in the host configuration when
(like any test) it will run in the target configuration. This means that
cross compilation will be broken and options that differ between host
and target (e.g. `NDEBUG`) will not be as set by the user.
I confirmed that without this fix, a test binary with `assert(false)`
passes when run under `native_test`.
Additionally, the use of `allow_single_file` precludes rules that return
multiple files in their DefaultInfo (like `py_binary`). Instead, we can
use `allow_files` and access via `ctx.executable`.
The current implementation misses the runfiles from the binary itself
since the attribute for it is called `src` not `srcs` and it makes use
of the discouraged `collect_data` and `collect_default` parameters which
depend on hardcoded attribute names.
kotlaja