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
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>
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.
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.
* 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/
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
native_binary() wraps a pre-built binary or script
in a *_binary rule interface. Rules like genrule
can tool-depend on it, and it can be executed with
"bazel run". This rule can also augment the binary
with runfiles.
native_test() is similar, but creates a testable
rule instead of a binary rule.
Fixes https://github.com/bazelbuild/bazel-skylib/issues/148
RELNOTES[NEW]: The new `native_binary()` and `native_test()` rules let you wrap a pre-built binary in a binary and test rule respectively.
The user can specify which line endings they want
write_file to use. This helps avoiding line ending
mismatches with diff_test.
Example: diff_test verifies that a rule generates
correct output by comparing it to a checked-in
"golden" file. Both files are text files, and the
user builds on Windows but the golden file was
written on Linux and git checkout preserved
original line endings.
Without explicitly specifying which line endings
to use, this diff_test would fail on an otherwise
good output.
With explicit line endings we don't need to check
in the golden file to git, we can just generate it
with "auto" line endings.
This new test rule compares two files and passes
if the files match.
On Linux/macOS/non-Windows, the test compares
files using 'diff'.
On Windows, the test compares files using
'fc.exe'. This utility is available on all Windows
versions I tried (Windows 2008 Server, Windows
2016 Datacenter Core).
See https://github.com/bazelbuild/bazel/issues/5508
See https://github.com/bazelbuild/bazel/issues/4319
Move maprule() to a private directory, to
discourage use of it. I (@laszlocsomor) am
planning breaking changes to it.
Also move private files (rule implementations) to
a subdirectory "rules/private/", to clean up the
"rules/" directory.
This PR adds two new rules: write_file and
write_xfile.
Both rules solve a common problem: to write a text
file with user-defined contents.
The problem is routinely solved using a genrule.
That however requires Bash, since genrules execute
Bash commands. Requiring Bash is a problem on
Windows.
The new rules do not require any shell.
The only difference between the rules is that
write_xfile creates an executable file while
write_file doesn't.
See https://github.com/bazelbuild/bazel/issues/4319
This PR adds two new rules: copy_file and
copy_xfile.
Both rules solve a common problem: to copy one
file to another location. The problem is routinely
solved using a genrule. That however requires
Bash, since genrules execute Bash commands.
Requiring Bash is a problem on Windows.
The new rules do not require Bash on Windows (only
on other platforms).
The only difference between the rules is that
copy_xfile creates an executable file while
copy_file doesn't.
See https://github.com/bazelbuild/bazel/issues/4319
