Shell Rules
Rules
sh_binary
sh_binary(name, deps, srcs, data, args, compatible_with, deprecation, distribs, env, exec_compatible_with, exec_properties, features, licenses, output_licenses, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
The sh_binary rule is used to declare executable Bourne shell scripts.
(sh_binary is a misnomer: its outputs aren't necessarily binaries.) This rule ensures
that all dependencies are built, and appear in the runfiles area at execution time.
We recommend that you name your sh_binary() rules after the name of the script minus
the extension (e.g. .sh); do not give the rule and the file the same name.
Example
For a simple shell script with no dependencies and some data files:
sh_binary(
name = "foo",
srcs = ["foo.sh"],
data = glob(["datafiles/*.txt"]),
)
Arguments
| Attributes | |
|---|---|
name |
A unique name for this target. |
deps
|
deps
at Attributes common to all build rules
.
This attribute should be used to list other |
srcs
|
This attribute must be a singleton list, whose element is the shell script.
This script must be executable, and may be a source file or a generated file.
All other files required at runtime (whether scripts or data) belong in the
|
sh_library
sh_library(name, deps, srcs, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)
The main use for this rule is to aggregate together a logical
"library" consisting of related scripts—programs in an
interpreted language that does not require compilation or linking,
such as the Bourne shell—and any data those programs need at
run-time. Such "libraries" can then be used from
the data attribute of one or
more sh_binary rules.
You can use the filegroup rule to aggregate data
files.
In interpreted programming languages, there's not always a clear
distinction between "code" and "data": after all, the program is
just "data" from the interpreter's point of view. For this reason
this rule has three attributes which are all essentially equivalent:
srcs, deps and data.
The current implementation does not distinguish between the elements of these lists.
All three attributes accept rules, source files and generated files.
It is however good practice to use the attributes for their usual purpose (as with other rules).
Examples
sh_library(
name = "foo",
data = [
":foo_service_script", # an sh_binary with srcs
":deploy_foo", # another sh_binary with srcs
],
)
Arguments
| Attributes | |
|---|---|
name |
A unique name for this target. |
deps
|
deps
at Attributes common to all build rules
.
This attribute should be used to list other |
srcs
|
This attribute should be used to list shell script source files that belong to
this library. Scripts can load other scripts using the shell's |
sh_test
sh_test(name, deps, srcs, data, args, compatible_with, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, licenses, local, restricted_to, shard_count, size, tags, target_compatible_with, testonly, timeout, toolchains, visibility)
A sh_test() rule creates a test written as a Bourne shell script.
See the attributes common to all test rules (*_test).
Examples
sh_test(
name = "foo_integration_test",
size = "small",
srcs = ["foo_integration_test.sh"],
deps = [":foo_sh_lib"],
data = glob(["testdata/*.txt"]),
)
Arguments
| Attributes | |
|---|---|
name |
A unique name for this target. |
deps
|
deps
at Attributes common to all build rules
.
This attribute should be used to list other |
srcs
|
This attribute must be a singleton list, whose element is the shell script.
This script must be executable, and may be a source file or a generated file.
All other files required at runtime (whether scripts or data) belong in the
|