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.
Adds a new module `modules` with two helper functions for module
extensions:
* `use_all_repos` makes it easy to return an appropriate
`extension_metadata` from a module extension (if supported) to
indicate that all repositories generated by the extension should be
imported via `use_repo`.
* `as_extension` turns a WORKSPACE macro into a module extension that
uses `use_all_repos` to automate the generation of `use_repo` calls.
Allow `bzl_library` to depend on non-`bzl_library` targets
Notably, `filegroup`. `bzl_library` doesn't actually read anything from the `StarlarkLibraryInfo` provider, and requiring all deps to be other `bzl_library` targets is really painful for anyone loading .bzls from `@bazel_tools` or `@platforms` because those core modules/repos don't want a dependency on Skylib just for access to `bzl_library`.
The medium-term plan will be to move `bzl_library` into `@bazel_tools`; but before then, this can serve as a stop-gap.
Co-authored-by: Alexandre Rostovtsev <arostovtsev@google.com>
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>
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.
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.
This is a relatively simple addition to unittest that statically creates rules
that either explicitly fail or not depending on if the test case is valid during
LOADING phase of bazel. The test conditions are evaluated entirely in loading
phase, but if we want an actual test to fail rather than just `fail()` killing
the build, we can use this to assert state and report test failures.
Due to grep having dropped support for handling line-ending matches in a cross-platform way, grepping for `...$` will now fail on Windows, as it no longer ignores the CR part of the CRLF line endings on Windows.
This should turn this project green again on Bazel CI.
* Enable unittest.suite to accept partial calls of rules
This permits using `unittest.suite` with test rules that have nondefault
attributes, while retaining compatibility with current usage.
For instance, this permits setting a `timeout` on each test in a
`unittest.suite`. Previously, all tests in a `unittest.suite` would
have the default timeout, with no good way to alter this. This
made it hard to eliminate all the warnings produced from using the
`--test_verbose_timeout_warnings` bazel option.
While timeouts were the motivation, the solution here is not specific
to timeouts. It will permit arbitrary additional arguments to the test
rules in a `unittest.suite`.
Fixes #98
* Respond to review feedback.
* Document a breaking change in bazel that this code needs to be aware of.
This should fix some buildkite CI flows, ensuring success of
this test is no longer tied to the current compilation_mode.
It also improves the error message of the offending evaluation.
* copy_file: Add parameter to allow symlinks
This change adds a new parameter `allow_symlinks` to `copy_file` that
allows the action to create a symlink instead of doing an expensive
copy if the execution platform (host) allows it.
Updates #248
* Update docs
* Refactor `is_executable` into attribute
* Fix typo
* s/_impl/_copy_file_impl/
Specifically:
selects.config_setting_group(
name = "always_true",
match_any = ["//conditions:default"],
)
and
selects.config_setting_group(
name = "always_true",
match_all = ["//conditions:default"],
)
These should, as expected, always evaluate to True.
Their implementation had a bug that failed the build outright.
* Create a helper rule for selecting a file from outputs of another rule or a filegroup by subpath
* Add tests
* Address code review comments
* + formatting
Co-authored-by: c-parsons <cparsons@google.com>
The output directories for the target under test may differ when the target is under a config transition (config_settings is passed to analysistest.make). Since analysis tests may assert about the command-line of generated actions, and those command-lines may contain paths to output files, this is useful information to expose.
* Add sets.is_set() to test whether an arbitrary object is a set.
Since using sets requires special API, it can be useful to determine
whether an object is a set so special handling can be used.
For example, if a method wants to be able to take a list or a set.
