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.
I find it more ergonomic to add notes or a description about a test to a `doc` attribute, similar to other rules, vs a comment block above it or in the `impl` function docstring. Hopefully this can improve the readability of test rules.
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.
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.
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.
Alexandre Rostovtsev