| <aid="run_binary-name"></a>name | The target name | none |
| <aid="run_binary-tool"></a>tool | The tool to run in the action.<br><br>Must be the label of a *_binary rule of a rule that generates an executable file, or of a file that can be executed as a subprocess (e.g. an .exe or .bat file on Windows or a binary with executable permission on Linux). This label is available for <code>$(location)</code> expansion in <code>args</code> and <code>env</code>. | none |
| <aid="run_binary-srcs"></a>srcs | Additional inputs of the action.<br><br>These labels are available for <code>$(location)</code> expansion in <code>args</code> and <code>env</code>. | <code>[]</code> |
| <aid="run_binary-args"></a>args | Command line arguments of the binary.<br><br>Subject to <code>$(location)</code> and makevar expansions. | <code>[]</code> |
| <aid="run_binary-env"></a>env | Environment variables of the action.<br><br>Subject to <code>$(location)</code> and makevar expansions. | <code>{}</code> |
| <aid="run_binary-outs"></a>outs | Output files generated by the action.<br><br>These labels are available for <code>$(location)</code> expansion in <code>args</code> and <code>env</code>.<br><br>Output files cannot be nested within output directories in out_dirs. | <code>[]</code> |
| <aid="run_binary-out_dirs"></a>out_dirs | Output directories generated by the action.<br><br>These labels are _not_ available for <code>$(location)</code> expansion in <code>args</code> and <code>env</code> sincew they are not pre-declared labels created via attr.output_list(). Output directories are declared instead by <code>ctx.actions.declare_directory</code>.<br><br>Output directories cannot be nested within other output directories in out_dirs. | <code>[]</code> |
| <aid="run_binary-mnemonic"></a>mnemonic | A one-word description of the action, for example, CppCompile or GoLink. | <code>"RunBinary"</code> |
| <aid="run_binary-progress_message"></a>progress_message | Progress message to show to the user during the build, for example, "Compiling foo.cc to create foo.o". The message may contain %{label}, %{input}, or %{output} patterns, which are substituted with label string, first input, or output's path, respectively. Prefer to use patterns instead of static strings, because the former are more efficient. | <code>None</code> |
| <aid="run_binary-execution_requirements"></a>execution_requirements | Information for scheduling the action.<br><br>For example,<br><br><pre><code> execution_requirements = { "no-cache": "1", }, </code></pre><br><br>See https://docs.bazel.build/versions/main/be/common-definitions.html#common.tags for useful keys. | <code>None</code> |
| <aid="run_binary-stamp"></a>stamp | Whether to include build status files as inputs to the tool. Possible values:<br><br>- <code>stamp = 1</code>: Always include build status files as inputs to the tool, even in [--nostamp](https://docs.bazel.build/versions/main/user-manual.html#flag--stamp) builds. This setting should be avoided, since it is non-deterministic. It potentially causes remote cache misses for the target and any downstream actions that depend on the result. - <code>stamp = 0</code>: Never include build status files as inputs to the tool. This gives good build result caching. - <code>stamp = -1</code>: Inclusion of build status files as inputs is controlled by the [--[no]stamp](https://docs.bazel.build/versions/main/user-manual.html#flag--stamp) flag. Stamped targets are not rebuilt unless their dependencies change.<br><br>When stamping is enabled, an additional two environment variables will be set for the action: - <code>BAZEL_STABLE_STATUS_FILE</code> - <code>BAZEL_VOLATILE_STATUS_FILE</code><br><br>These files can be read and parsed by the action, for example to pass some values to a linker. | <code>-1</code> |
| <aid="run_binary-output_dir"></a>output_dir | If set to True then an output directory named the same as the target name is added to out_dirs.<br><br>Deprecated. For backward compatability with @aspect_bazel_lib 1.x. Use out_dirs instead. | <code>False</code> |