Command-line reference ¶

This page contains every public Bessemer command and option. Start with the beginner view, bsmr -h. Use this page when that interface is not enough.

`bsmr audit`¶

Perform lower level queries

Usage: bsmr audit <COMMAND>

Subcommands:¶

cell: Query information about the [cells] list in .bsmr.
file-package: Map file paths to fully qualified package names.
classpath: Prints out a target's classpaths if it has one. This command is deprecated and currently available for compatibility with legacy. We will replace this command with something that can audit the entire TemplatePlaceholderInfo in the future.
config: Read and display bsmrconfig values.
configurations: prints the constraints for configuration IDs
includes: list build file extensions imported at parse time.
prelude: print the interpreter prelude to stdout
providers: prints out the providers for a target pattern
subtargets: Print all subtargets
analysis-queries: bsmr audit analysis resolving query attrs
execution-platform-resolution: prints out information about execution platform resolution
visibility: Verify the visibility for transitive deps of the specified target(s) on the unconfigured target graph
starlark: Debug Starlark interpreter
dep-files: prints out the select files for a command
deferred-materializer: Access and interact with the deferred materializer
output: Query the action that produced the output artifact. Does not support BXL, test, scratch, or anon artifacts. If the configuration hash of the output path does not match the current platform configuration, the unconfigured target label will be returned.
parse: Parses the bsmr-out path into parts that may be useful (ex: config hash, file path to artifact).
package-values: Inspect package values, visibility, within_view and visibility_cap

Common Options:¶

Common options are documented under Global options.

`bsmr audit cell`¶

Query information about the [cells] list in .bsmr.

Usage: bsmr audit cell [OPTIONS] [CELL_ALIASES]...

Arguments:¶

<CELL_ALIASES> Cell aliases to query. These aliases will be resolved in the working directory cell.

Common Options:¶

Common options are documented under Global options.

Options:¶

--json Output in JSON format
--paths-only Don't include the cell name in the output
--aliases If enabled and no explicit aliases are passed, will query for all aliases in the working directory cell.
-m, --modifier <VALUE> This option is not used
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr audit file-package`¶

Map file paths to fully qualified package names.

Usage: bsmr audit file-package [OPTIONS] [PATHS]...

Arguments:¶

<PATHS> File paths to resolve to package names (build files, directories, or any source files)

Common Options:¶

Common options are documented under Global options.

Options:¶

--json Output in JSON format
-m, --modifier <VALUE> This option is not used
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

Prints out a target's classpaths if it has one. This command is deprecated and currently available for compatibility with legacy. We will replace this command with something that can audit the entire TemplatePlaceholderInfo in the future.

Usage: bsmr audit classpath [OPTIONS] [TARGET_PATTERNS]...

Arguments:¶

<TARGET_PATTERNS> Target patterns to audit

Common Options:¶

Common options are documented under Global options.

Options:¶

--json Output in JSON format
--target-platforms <PLATFORM> Configuration target (one) to use to configure targets
-m, --modifier <VALUE> A configuration modifier to configure all targets on the command line. This may be a constraint value target.
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr audit config`¶

Read and display bsmrconfig values.

Usage: bsmr audit config [OPTIONS] [SPECS]...

Arguments:¶

<SPECS> config section/key specs of the form section or section.key. If any specs are provided, only values matching a spec will be printed (section headers will be printed only for sections with a key matching the spec)

Common Options:¶

Common options are documented under Global options.

Options:¶

--cell <CELL> Query config for a specific cell (default: the cell of the current working directory)
--all-cells Produce information for all cells
--output-format <OUTPUT_FORMAT> Output format
- Possible values:
  - simple
  - inline_section
  - json
- --json Output in JSON format (shorthand for --output-format=json)
--location <LOCATION_STYLE> Show where config values are defined
- Default value: none
- Possible values:
  - none
  - direct
  - extended
- --value <VALUE_STYLE> Show resolved values, raw (pre-substitution) values, or both
- Default value: resolved
- Possible values:
  - resolved
  - raw
  - both
- -m, --modifier <VALUE> This option is not used
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr audit configurations`¶

prints the constraints for configuration IDs

Usage: bsmr audit configurations [OPTIONS] [configurations]...

Arguments:¶

<configurations> configurations to audit (example: cell//package:target-105fe3389fc7e436). If none provided, will print information about all known configurations.

Common Options:¶

Common options are documented under Global options.

Options:¶

-m, --modifier <VALUE> This option is not used
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr audit includes`¶

list build file extensions imported at parse time.

Usage: bsmr audit includes [OPTIONS] [BUILD_FILES]...

Arguments:¶

<BUILD_FILES> Build files to audit. These are expected to be relative paths from the working dir cell.

Common Options:¶

Common options are documented under Global options.

Options:¶

--json Print json representation of outputs
-m, --modifier <VALUE> This option is not used
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr audit prelude`¶

print the interpreter prelude to stdout

Usage: bsmr audit prelude [OPTIONS]

Common Options:¶

Common options are documented under Global options.

Options:¶

-m, --modifier <VALUE> This option is not used
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr audit providers`¶

prints out the providers for a target pattern

Usage: bsmr audit providers [OPTIONS] <TARGET_PATTERNS>...

Arguments:¶

<TARGET_PATTERNS> Patterns to analyze

Common Options:¶

Common options are documented under Global options.

Options:¶

--quiet
-l, --list List the available providers
--print-debug Print the providers using debug format (very verbose)
-p, --provider <PROVIDER> Print only the named provider(s)
-u, --target-universe <TARGET_UNIVERSE> Comma separated list of targets to construct a configured target universe.

When the option is specified, command targets are be resolved in this universe. Additionally, --target-platforms= and --modifier= flags are be used to configure the universe targets, not the command targets.

This argument is particularly recommended on most non-trivial cqueries. In the absence of this argument, bsmr will use the target literals in your cquery expression as the value for this argument, which may not be what you want.
--target-platforms <PLATFORM> Configuration target (one) to use to configure targets
-m, --modifier <VALUE> A configuration modifier to configure all targets on the command line. This may be a constraint value target.
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr audit subtargets`¶

Print all subtargets

Usage: bsmr audit subtargets [OPTIONS] <TARGET_PATTERNS>...

Arguments:¶

<TARGET_PATTERNS> Patterns to analyze

Common Options:¶

Common options are documented under Global options.

Options:¶

--shallow Do not recursively print all nested subtargets; print only the first level. This is set to false by default
--json Print subtargets as JSON
-u, --target-universe <TARGET_UNIVERSE> Comma separated list of targets to construct a configured target universe.

When the option is specified, command targets are be resolved in this universe. Additionally, --target-platforms= and --modifier= flags are be used to configure the universe targets, not the command targets.

This argument is particularly recommended on most non-trivial cqueries. In the absence of this argument, bsmr will use the target literals in your cquery expression as the value for this argument, which may not be what you want.
--target-platforms <PLATFORM> Configuration target (one) to use to configure targets
-m, --modifier <VALUE> A configuration modifier to configure all targets on the command line. This may be a constraint value target.
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr audit analysis-queries`¶

bsmr audit analysis resolving query attrs

Usage: bsmr audit analysis-queries [OPTIONS] [TARGET_PATTERNS]...

Arguments:¶

<TARGET_PATTERNS> Patterns to evaluate. The query attributes for targets matching these patterns will be evaluated

Common Options:¶

Common options are documented under Global options.

Options:¶

--include-outputs Enable to print the outputs for the targets in the resolved queries
-u, --target-universe <TARGET_UNIVERSE> Comma separated list of targets to construct a configured target universe.

When the option is specified, command targets are be resolved in this universe. Additionally, --target-platforms= and --modifier= flags are be used to configure the universe targets, not the command targets.

This argument is particularly recommended on most non-trivial cqueries. In the absence of this argument, bsmr will use the target literals in your cquery expression as the value for this argument, which may not be what you want.
--target-platforms <PLATFORM> Configuration target (one) to use to configure targets
-m, --modifier <VALUE> A configuration modifier to configure all targets on the command line. This may be a constraint value target.
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr audit execution-platform-resolution`¶

prints out information about execution platform resolution

Usage: bsmr audit execution-platform-resolution [OPTIONS] [TARGET_PATTERNS]...

Arguments:¶

<TARGET_PATTERNS> Patterns to analyze

Common Options:¶

Common options are documented under Global options.

Options:¶

-u, --target-universe <TARGET_UNIVERSE> Comma separated list of targets to construct a configured target universe.

When the option is specified, command targets are be resolved in this universe. Additionally, --target-platforms= and --modifier= flags are be used to configure the universe targets, not the command targets.

This argument is particularly recommended on most non-trivial cqueries. In the absence of this argument, bsmr will use the target literals in your cquery expression as the value for this argument, which may not be what you want.
--target-platforms <PLATFORM> Configuration target (one) to use to configure targets
-m, --modifier <VALUE> A configuration modifier to configure all targets on the command line. This may be a constraint value target.
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr audit visibility`¶

Verify the visibility for transitive deps of the specified target(s) on the unconfigured target graph

Usage: bsmr audit visibility [OPTIONS] [TARGET_PATTERNS]...

Arguments:¶

<TARGET_PATTERNS> Target pattern(s) to analyze.

Common Options:¶

Common options are documented under Global options.

Options:¶

-m, --modifier <VALUE> This option is not used
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr audit starlark`¶

Debug Starlark interpreter

Usage: bsmr audit starlark <COMMAND>

Subcommands:¶

module: Inspect Starlark module by fully qualified import string like foo//bar:baz.bzl
package-deps: Inspect Starlark package file all bzl dependencies by package name like foo//bar/baz

Common Options:¶

Common options are documented under Global options.

`bsmr audit starlark module`¶

Inspect Starlark module by fully qualified import string like foo//bar:baz.bzl

Usage: bsmr audit starlark module [OPTIONS] <IMPORT_PATH>

Arguments:¶

<IMPORT_PATH> Module import path

Common Options:¶

Common options are documented under Global options.

Options:¶

-m, --modifier <VALUE> This option is not used
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr audit starlark package-deps`¶

Inspect Starlark package file all bzl dependencies by package name like foo//bar/baz

Usage: bsmr audit starlark package-deps [OPTIONS] <PACKAGE>

Arguments:¶

<PACKAGE> Package

Common Options:¶

Common options are documented under Global options.

Options:¶

-m, --modifier <VALUE> This option is not used
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr audit dep-files`¶

prints out the select files for a command

Usage: bsmr audit dep-files [OPTIONS] <PATTERN> <CATEGORY> [IDENTIFIER]

Arguments:¶

<PATTERN> Target to query dep files for
<CATEGORY> Action category
<IDENTIFIER> Action identifier

Common Options:¶

Common options are documented under Global options.

Options:¶

--target-platforms <PLATFORM> Configuration target (one) to use to configure targets
-m, --modifier <VALUE> A configuration modifier to configure all targets on the command line. This may be a constraint value target.
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr audit deferred-materializer`¶

Access and interact with the deferred materializer

Usage: bsmr audit deferred-materializer [OPTIONS] <COMMAND>

Subcommands:¶

list
list-subscriptions
fsck
refresh
get-refresh-log: Get the log for TTL refreshes
test-iter
flush-access-times

Common Options:¶

Common options are documented under Global options.

Options:¶

-m, --modifier <VALUE> This option is not used
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none
bsmr audit deferred-materializer list¶

Usage: bsmr audit deferred-materializer list

Common Options:¶

Common options are documented under Global options.

`bsmr audit deferred-materializer list-subscriptions`¶

Usage: bsmr audit deferred-materializer list-subscriptions

Common Options:¶

Common options are documented under Global options.

`bsmr audit deferred-materializer fsck`¶

Usage: bsmr audit deferred-materializer fsck

Common Options:¶

Common options are documented under Global options.

`bsmr audit deferred-materializer refresh`¶

Usage: bsmr audit deferred-materializer refresh <MIN_TTL>

Arguments:¶

<MIN_TTL> Minimum TTL to require for actions

Common Options:¶

Common options are documented under Global options.

`bsmr audit deferred-materializer get-refresh-log`¶

Get the log for TTL refreshes

Usage: bsmr audit deferred-materializer get-refresh-log

Common Options:¶

Common options are documented under Global options.

`bsmr audit deferred-materializer test-iter`¶

Usage: bsmr audit deferred-materializer test-iter [OPTIONS]

Common Options:¶

Common options are documented under Global options.

Options:¶

--count <COUNT>
- Default value: 1

`bsmr audit deferred-materializer flush-access-times`¶

Usage: bsmr audit deferred-materializer flush-access-times

Common Options:¶

Common options are documented under Global options.

`bsmr audit output`¶

Query the action that produced the output artifact. Does not support BXL, test, scratch, or anon artifacts. If the configuration hash of the output path does not match the current platform configuration, the unconfigured target label will be returned.

Usage: bsmr audit output [OPTIONS] <OUTPUT_PATH>

Arguments:¶

<OUTPUT_PATH> The bsmr-out path to the build artifact, starting with bsmr-out and including the configuration platform.

Common Options:¶

Common options are documented under Global options.

Options:¶

--json
-A, --output-all-attributes Output all attributes, equivalent of --output-attribute ''.

Avoid using this flag in automation because it may be expensive to produce certain attributes, and because it makes harder to track which special attributes are used.
-B, --output-basic-attributes Output basic attributes, namely those the user can supply, plus rule type and package name
-a, --output-attribute <ATTRIBUTE> Regular expressions to match attributes. Regular expressions are used in "search" mode, so for example empty string matches all attributes including special attributes.

When using in automation, please specify the regular expression to match the attribute precisely, for example --output-attribute '^headers$' to make it easier to track which special attributes are used.
--output-attributes <ATTRIBUTE> Deprecated: Use --output-attribute instead.

List of space-separated attributes to output, --output-attributes attr1 attr2.
--target-platforms <PLATFORM> Configuration target (one) to use to configure targets
-m, --modifier <VALUE> A configuration modifier to configure all targets on the command line. This may be a constraint value target.
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr audit parse`¶

Parses the bsmr-out path into parts that may be useful (ex: config hash, file path to artifact).

Usage: bsmr audit parse [OPTIONS] <OUTPUT_PATH>

Arguments:¶

<OUTPUT_PATH> The bsmr-out path to the build artifact, starting with bsmr-out and including the configuration platform.

Common Options:¶

Common options are documented under Global options.

Options:¶

--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr audit package-values`¶

Inspect package values, visibility, within_view and visibility_cap.

Package values are set with write_package_value function from PACKAGE files. Visibility and within_view come from the package() function in PACKAGE files. Visibility_cap comes from enforce_visibility_intersection() in PACKAGE files.

Usage: bsmr audit package-values [OPTIONS] [PACKAGES]...

Arguments:¶

<PACKAGES> Package names to inspect (like //foo/bar, no trailing colon)

Common Options:¶

Common options are documented under Global options.

Options:¶

-m, --modifier <VALUE> This option is not used
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr aquery`¶

Perform queries on the action graph (experimental)

The action graph consists of all the declared actions for a build, with dependencies when one action consumes the outputs of another action.

Run bsmr docs aquery or https://oss.dedaluslabs.ai/bsmr/users/query/aquery/ for more documentation about the functions available in aquery expressions.

Examples:

Print the action producing a target's default output

bsmr aquery //java/com/example/app:amazing

List all the commands for run actions for building a target

bsmr aquery 'kind(run, deps("//java/com/example/app:amazing+more"))' --output-attribute=cmd

Dynamic outputs (ctx.actions.dynamic_output):

Currently, aquery interacts poorly with dynamic outputs. It may return incorrect results or otherwise behave unexpectedly.

Usage: bsmr aquery [OPTIONS] <QUERY> [QUERY_ARGS]...

Arguments:¶

<QUERY> the query to evaluate
<QUERY_ARGS> list of literals for a multi-query (one containing %s or %Ss)

Common Options:¶

Common options are documented under Global options.

Options:¶

-A, --output-all-attributes Output all attributes, equivalent of --output-attribute ''.

Avoid using this flag in automation because it may be expensive to produce certain attributes, and because it makes harder to track which special attributes are used.
-B, --output-basic-attributes Output basic attributes, namely those the user can supply, plus rule type and package name
-a, --output-attribute <ATTRIBUTE> Regular expressions to match attributes. Regular expressions are used in "search" mode, so for example empty string matches all attributes including special attributes.

When using in automation, please specify the regular expression to match the attribute precisely, for example --output-attribute '^headers$' to make it easier to track which special attributes are used.
--output-attributes <ATTRIBUTE> Deprecated: Use --output-attribute instead.

List of space-separated attributes to output, --output-attributes attr1 attr2.
--json Output in JSON format
--dot Output in Graphviz Dot format
--dot-compact Output in a more compact format than Graphviz Dot

--output-format <dot|dot_compact|json|starlark> Output format (default: list).

       dot -  dot graph format.

       dot_compact - compact alternative to dot format.

       json - JSON format.

       starlark - targets are printed like starlark code that would produce them.

Possible values:
- dot
- json
- dot_compact
- starlark
--target-platforms <PLATFORM> Configuration target (one) to use to configure targets

-m, --modifier <VALUE> A configuration modifier to configure all targets on the command line. This may be a constraint value target.
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr build`¶

Build a package and its dependencies. Run from your project root.

Examples:

bsmr build apps/api
bsmr build apps/api --show-output

Use the package directory or an explicit target pattern. Project requirements: https://oss.dedaluslabs.ai/bsmr/getting_started/quickstart/

Usage: bsmr build [OPTIONS] [TARGET_PATTERNS]...

Arguments:¶

<TARGET_PATTERNS> Patterns to build
- Default value: .

Common Options:¶

Common options are documented under Global options.

Options:¶

--snapshot <PATH> Capture an experimental file-only dependency lock without replacing an existing file
--show-output Print the path to the output for each of the rules relative to the project root
--show-full-output Print the absolute path to the output for each of the rules
--show-simple-output Print only the path to the output for each of the rules relative to the project root
--show-full-simple-output Print only the absolute path to the output for each of the rules
--show-json-output Print the output paths relative to the project root, in JSON format
--show-full-json-output Print the output absolute paths, in JSON format
-M, --materializations <MATERIALIZATIONS> Materialize (or skip) the final artifacts, bypassing bsmrconfig.
- Possible values:
  - all
  - none
- --upload-final-artifacts <UPLOAD_FINAL_ARTIFACTS> Upload (or skip) the final artifacts.
- Possible values:
  - always
  - never
- --build-default-info Build default info (this is the default)
--skip-default-info Do not build default info (this is not the default)
--build-run-info Build runtime dependencies (this is the default)
--skip-run-info Do not build runtime dependencies (this is not the default)
--build-test-info Build tests (this is not the default)
--skip-test-info Do not build tests (this is the default)
--out <OUTPUT_PATH> Copy the output of the built target to this path (- to stdout)
--build-report <PATH> Print a build report

--build-report=- will print the build report to stdout --build-report=<filepath> will write the build report to the file
--enable-optional-validations <VALIDATION_NAMES> Comma separated list of validation names to run that are marked optional.

By default, validations marked as optional are skipped. This option overrides the behaviour and executes those validations.
--build-report-options <BUILD_REPORT_OPTIONS> Comma separated list of build report options.

The following options are supported:

fill-out-failures: fill out failures the same way Legacy would.

package-project-relative-paths: emit the project-relative path of packages for the targets that were built.

exclude-action-error-diagnostics: exclude error_diagnostics field from action errors in the build report.

truncate-error-content: truncate error content in the build report to reduce size.
--streaming-build-report <PATH> Stream intermediary build reports to a file in json lines format.

Each output materialization will trigger a new build report which will be written to the file as a single line json.
-j, --num-threads <THREADS> Number of threads to use during execution (default is # cores)
--sandbox Execute every action in a fresh networkless Firecracker microVM
--local-only Enable only local execution. Will reject actions that cannot execute locally
--remote-only Enable only remote execution. Will reject actions that cannot execute remotely
--prefer-local Enable hybrid execution. Will prefer executing actions that can execute locally on the local host
--prefer-remote Enable hybrid execution. Will prefer executing actions that can execute remotely on RE and will avoid racing local and remote execution
--unstable-no-execution Experimental: Disable all execution
--no-remote-cache Do not perform remote cache queries or cache writes. If remote execution is enabled, the RE service might still deduplicate actions, so for e.g. benchmarking, using a random isolation dir is preferred
--write-to-cache-anyway Could be used to enable the action cache writes on the RE worker when no_remote_cache is specified
--eager-dep-files Process dep files when they are generated (i.e. after running a command that produces dep files), rather than when they are used (i.e. before re-running a command that previously produced dep files). Use this when debugging commands that produce dep files. Note that commands that previously produced dep files will not re-run: only dep files produced during this command will be eagerly loaded
--upload-all-actions Uploads every action to the RE service, regardless of whether the action needs to execute on RE.

This is useful when debugging builds and trying to inspect actions which executed remotely. It's possible that the action result is cached but the action itself has expired. In this case, downloading the action itself would fail. Enabling this option would unconditionally upload all actions, thus you will not hit any expiration issues.
--fail-fast If Bsmr hits an error, do as little work as possible before exiting.

To illustrate the effect of this flag, consider an invocation of build :foo :bar. The default behavior of bsmr is to do enough work to get a result for the builds of each of :foo and :bar, and no more. This means that bsmr will continue to complete the build of :bar after the build of :foo has failed; however, once one dependency of :foo has failed, other dependencies will be cancelled unless they are needed by :bar.

This flag changes the behavior of bsmr to not wait on :bar to complete once :foo has failed. Generally, this flag only has an effect on builds that specify multiple targets.

--keep-going changes the behavior of bsmr to not only wait on :bar once one dependency of :foo has failed, but to additionally attempt to build other dependencies of :foo if possible.
--keep-going If Bsmr hits an error, continue doing as much work as possible before exiting.

See --fail-fast for more details.
--skip-missing-targets If target is missing, then skip building instead of throwing error
--skip-incompatible-targets If target is incompatible with the specified configuration, skip building instead of throwing error. This does not apply to targets specified with glob patterns /... or : which are skipped unconditionally
--materialize-failed-inputs Materializes inputs for failed actions which ran on RE
--materialize-failed-outputs Materializes outputs (if present) for failed actions which ran on RE
-u, --target-universe <TARGET_UNIVERSE> Comma separated list of targets to construct a configured target universe.

When the option is specified, command targets are be resolved in this universe. Additionally, --target-platforms= and --modifier= flags are be used to configure the universe targets, not the command targets.

This argument is particularly recommended on most non-trivial cqueries. In the absence of this argument, bsmr will use the target literals in your cquery expression as the value for this argument, which may not be what you want.
--target-platforms <PLATFORM> Configuration target (one) to use to configure targets
-m, --modifier <VALUE> A configuration modifier to configure all targets on the command line. This may be a constraint value target.
--overall-timeout <TIMEOUT> How long to run the command for. If the timeout is exceeded, Bessemer will exit as quickly as possible and not run further builds or tests.

In-flight builds and tests will be cancelled. The test orchestrator, if there is one, will be allowed to shut down gracefully.

The exit code for builds will be a user error, for tests it is controlled by the test orchestrator (which normally should report zero for this).

The format is a concatenation of time spans (separated by spaces). Each time span is an integer number and a suffix.

Relevant supported suffixes: seconds, second, sec, s, minutes, minute, min, m, hours, hour, hr, h

For example: 5m 10s, 500s.
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr bxl`¶

Run BXL scripts

Usage: bsmr bxl [OPTIONS] <BXL label> [-- <BXL INPUT ARGS>...]

Arguments:¶

<BXL label> The bxl function to execute as defined by the label of form <cell>//path/file.bxl:<function>
<BXL INPUT ARGS> Arguments passed to the bxl script

Common Options:¶

Common options are documented under Global options.

Options:¶

-M, --materializations <MATERIALIZATIONS> Materialize (or skip) the final artifacts, bypassing bsmrconfig.
- Possible values:
  - all
  - none
- --upload-final-artifacts <UPLOAD_FINAL_ARTIFACTS> Upload (or skip) the final artifacts.
- Possible values:
  - always
  - never
- --user-event-log <PATH> Write user events to this log file. Both user and internal events are written to main event log. If this flag is specified, user events are additionally written to user event log. Log format is JSONL, uncompressed if no known extensions are detected, or you can explicitly specify the compression via the file extension (ex: .json-lines.gz would be gzip compressed, .json-lines.zst would be zstd compressed). Resulting log is compatible with bsmr log show-user
--build-report <PATH> Print a build report

--build-report=- will print the build report to stdout --build-report=<filepath> will write the build report to the file
--enable-optional-validations <VALIDATION_NAMES> Comma separated list of validation names to run that are marked optional.

By default, validations marked as optional are skipped. This option overrides the behaviour and executes those validations.
--build-report-options <BUILD_REPORT_OPTIONS> Comma separated list of build report options.

The following options are supported:

fill-out-failures: fill out failures the same way Legacy would.

package-project-relative-paths: emit the project-relative path of packages for the targets that were built.

exclude-action-error-diagnostics: exclude error_diagnostics field from action errors in the build report.

truncate-error-content: truncate error content in the build report to reduce size.
--streaming-build-report <PATH> Stream intermediary build reports to a file in json lines format.

Each output materialization will trigger a new build report which will be written to the file as a single line json.
-j, --num-threads <THREADS> Number of threads to use during execution (default is # cores)
--sandbox Execute every action in a fresh networkless Firecracker microVM
--local-only Enable only local execution. Will reject actions that cannot execute locally
--remote-only Enable only remote execution. Will reject actions that cannot execute remotely
--prefer-local Enable hybrid execution. Will prefer executing actions that can execute locally on the local host
--prefer-remote Enable hybrid execution. Will prefer executing actions that can execute remotely on RE and will avoid racing local and remote execution
--unstable-no-execution Experimental: Disable all execution
--no-remote-cache Do not perform remote cache queries or cache writes. If remote execution is enabled, the RE service might still deduplicate actions, so for e.g. benchmarking, using a random isolation dir is preferred
--write-to-cache-anyway Could be used to enable the action cache writes on the RE worker when no_remote_cache is specified
--eager-dep-files Process dep files when they are generated (i.e. after running a command that produces dep files), rather than when they are used (i.e. before re-running a command that previously produced dep files). Use this when debugging commands that produce dep files. Note that commands that previously produced dep files will not re-run: only dep files produced during this command will be eagerly loaded
--upload-all-actions Uploads every action to the RE service, regardless of whether the action needs to execute on RE.

This is useful when debugging builds and trying to inspect actions which executed remotely. It's possible that the action result is cached but the action itself has expired. In this case, downloading the action itself would fail. Enabling this option would unconditionally upload all actions, thus you will not hit any expiration issues.
--fail-fast If Bsmr hits an error, do as little work as possible before exiting.

To illustrate the effect of this flag, consider an invocation of build :foo :bar. The default behavior of bsmr is to do enough work to get a result for the builds of each of :foo and :bar, and no more. This means that bsmr will continue to complete the build of :bar after the build of :foo has failed; however, once one dependency of :foo has failed, other dependencies will be cancelled unless they are needed by :bar.

This flag changes the behavior of bsmr to not wait on :bar to complete once :foo has failed. Generally, this flag only has an effect on builds that specify multiple targets.

--keep-going changes the behavior of bsmr to not only wait on :bar once one dependency of :foo has failed, but to additionally attempt to build other dependencies of :foo if possible.
--keep-going If Bsmr hits an error, continue doing as much work as possible before exiting.

See --fail-fast for more details.
--skip-missing-targets If target is missing, then skip building instead of throwing error
--skip-incompatible-targets If target is incompatible with the specified configuration, skip building instead of throwing error. This does not apply to targets specified with glob patterns /... or : which are skipped unconditionally
--materialize-failed-inputs Materializes inputs for failed actions which ran on RE
--materialize-failed-outputs Materializes outputs (if present) for failed actions which ran on RE
--target-platforms <PLATFORM> Configuration target (one) to use to configure targets
-m, --modifier <VALUE> A configuration modifier to configure all targets on the command line. This may be a constraint value target.
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr help-env`¶

Print help for environment variables used by bsmr

Usage: bsmr help-env [OPTIONS]

Common Options:¶

Common options are documented under Global options.

Options:¶

--self-testing Also print those environment variables that are only used for bsmr integration tests.

These are all unstable and not meant to be used by most users.

`bsmr test`¶

Build and run tests associated with a package.

Example:

bsmr test app

Use the package directory or an explicit target pattern. Available tests depend on your project's language and configuration. Language guides: https://oss.dedaluslabs.ai/bsmr/about/language_support/

Usage: bsmr test [OPTIONS] [TARGET_PATTERNS]... [-- <TEST_EXECUTOR_ARGS>...]

Arguments:¶

<TARGET_PATTERNS> Patterns to test
- Default value: .
- <TEST_EXECUTOR_ARGS> Additional arguments passed to the test executor.
Test executor is expected to have --env flag to pass environment variables. Can be used like this:

bsmr test //foo:bar -- --env PRIVATE_KEY=123

Common Options:¶

Common options are documented under Global options.

Options:¶

--exclude <EXCLUDE> Labels on targets to exclude from tests
--include <INCLUDE> Labels on targets to include from tests. Prefixing with ! means to exclude. First match wins unless overridden by always-exclude flag. If include patterns are present, regardless of whether exclude patterns are present, then all targets are by default excluded unless explicitly included.
--always-exclude Whether to always exclude if the label appears in exclude, regardless of which appears first
--build-filtered Whether to build tests that are excluded via labels.
--unstable-allow-compatible-tests-on-re Will allow tests that are compatible with RE (setup to run from the repo root and use relative paths) to run from RE
--unstable-allow-all-tests-on-re Will run tests to on RE even if they are missing required settings (running from the root + relative paths). Those required settings just get overridden
--test-executor-stdout <TEST_EXECUTOR_STDOUT> Writes the test executor stdout to the provided path

--test-executor-stdout=- will write to stdout

--test-executor-stdout=FILEPATH will write to the provided filepath, overwriting the current file if it exists

By default the test executor's stdout stream is captured
--ignore-tests-attribute Normally testing will follow the tests attribute of all targets, to find their associated tests. When passed, this flag will disable that, and only run the directly supplied targets
--test-executor-stderr <TEST_EXECUTOR_STDERR> Writes the test executor stderr to the provided path

--test-executor-stderr=- will write to stderr

--test-executor-stderr=FILEPATH will write to the provided filepath, overwriting the current file if it exists

By default test executor's stderr stream is captured
--build-default-info Also build DefaultInfo provider, which is what bsmr build command builds (this is not the default)
--skip-default-info Do not build DefaultInfo provider (this is the default)
--build-run-info Also build RunInfo provider, which builds artifacts needed for bsmr run (this is not the default)
--skip-run-info Do not build RunInfo provider (this is the default)
--build-report <PATH> Print a build report

--build-report=- will print the build report to stdout --build-report=<filepath> will write the build report to the file
--enable-optional-validations <VALIDATION_NAMES> Comma separated list of validation names to run that are marked optional.

By default, validations marked as optional are skipped. This option overrides the behaviour and executes those validations.
--build-report-options <BUILD_REPORT_OPTIONS> Comma separated list of build report options.

The following options are supported:

fill-out-failures: fill out failures the same way Legacy would.

package-project-relative-paths: emit the project-relative path of packages for the targets that were built.

exclude-action-error-diagnostics: exclude error_diagnostics field from action errors in the build report.

truncate-error-content: truncate error content in the build report to reduce size.
--streaming-build-report <PATH> Stream intermediary build reports to a file in json lines format.

Each output materialization will trigger a new build report which will be written to the file as a single line json.
-j, --num-threads <THREADS> Number of threads to use during execution (default is # cores)
--sandbox Execute every action in a fresh networkless Firecracker microVM
--local-only Enable only local execution. Will reject actions that cannot execute locally
--remote-only Enable only remote execution. Will reject actions that cannot execute remotely
--prefer-local Enable hybrid execution. Will prefer executing actions that can execute locally on the local host
--prefer-remote Enable hybrid execution. Will prefer executing actions that can execute remotely on RE and will avoid racing local and remote execution
--unstable-no-execution Experimental: Disable all execution
--no-remote-cache Do not perform remote cache queries or cache writes. If remote execution is enabled, the RE service might still deduplicate actions, so for e.g. benchmarking, using a random isolation dir is preferred
--write-to-cache-anyway Could be used to enable the action cache writes on the RE worker when no_remote_cache is specified
--eager-dep-files Process dep files when they are generated (i.e. after running a command that produces dep files), rather than when they are used (i.e. before re-running a command that previously produced dep files). Use this when debugging commands that produce dep files. Note that commands that previously produced dep files will not re-run: only dep files produced during this command will be eagerly loaded
--upload-all-actions Uploads every action to the RE service, regardless of whether the action needs to execute on RE.

This is useful when debugging builds and trying to inspect actions which executed remotely. It's possible that the action result is cached but the action itself has expired. In this case, downloading the action itself would fail. Enabling this option would unconditionally upload all actions, thus you will not hit any expiration issues.
--fail-fast If Bsmr hits an error, do as little work as possible before exiting.

To illustrate the effect of this flag, consider an invocation of build :foo :bar. The default behavior of bsmr is to do enough work to get a result for the builds of each of :foo and :bar, and no more. This means that bsmr will continue to complete the build of :bar after the build of :foo has failed; however, once one dependency of :foo has failed, other dependencies will be cancelled unless they are needed by :bar.

This flag changes the behavior of bsmr to not wait on :bar to complete once :foo has failed. Generally, this flag only has an effect on builds that specify multiple targets.

--keep-going changes the behavior of bsmr to not only wait on :bar once one dependency of :foo has failed, but to additionally attempt to build other dependencies of :foo if possible.
--keep-going If Bsmr hits an error, continue doing as much work as possible before exiting.

See --fail-fast for more details.
--skip-missing-targets If target is missing, then skip building instead of throwing error
--skip-incompatible-targets If target is incompatible with the specified configuration, skip building instead of throwing error. This does not apply to targets specified with glob patterns /... or : which are skipped unconditionally
--materialize-failed-inputs Materializes inputs for failed actions which ran on RE
--materialize-failed-outputs Materializes outputs (if present) for failed actions which ran on RE
--target-platforms <PLATFORM> Configuration target (one) to use to configure targets
-m, --modifier <VALUE> A configuration modifier to configure all targets on the command line. This may be a constraint value target.
--overall-timeout <TIMEOUT> How long to run the command for. If the timeout is exceeded, Bessemer will exit as quickly as possible and not run further builds or tests.

In-flight builds and tests will be cancelled. The test orchestrator, if there is one, will be allowed to shut down gracefully.

The exit code for builds will be a user error, for tests it is controlled by the test orchestrator (which normally should report zero for this).

The format is a concatenation of time spans (separated by spaces). Each time span is an integer number and a suffix.

Relevant supported suffixes: seconds, second, sec, s, minutes, minute, min, m, hours, hour, hr, h

For example: 5m 10s, 500s.
--write-test-id <PATH> Write the test session ID into this file
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr cquery`¶

Perform queries on the configured target graph

The configured target graph includes information about the configuration (platforms) and transitions involved in building targets. In the configured graph, selects are fully resolved. The same target may appear in multiple different configurations (when printed, the configuration is after the target in parentheses).

A user can specify a --target-universe flag to control how literals are resolved. When provided, any literals will resolve to all matching targets within the universe (which includes the targets passed as the universe and all transitive deps of them). When not provided, we implicitly set the universe to be rooted at every target literal in the cquery.

Run bsmr docs cquery or https://oss.dedaluslabs.ai/bsmr/users/query/cquery/ for more documentation about the functions available in cquery expressions.

Examples:

Print all the attributes of a target

bsmr cquery //java/com/example/app:amazing --output-all-attributes

List the deps of a target (special characters in a target will require quotes):

bsmr cquery 'deps("//java/com/example/app:amazing+more")'

Usage: bsmr cquery [OPTIONS] <QUERY> [QUERY_ARGS]...

Arguments:¶

<QUERY> the query to evaluate
<QUERY_ARGS> list of literals for a multi-query (one containing %s or %Ss)

Common Options:¶

Common options are documented under Global options.

Options:¶

-A, --output-all-attributes Output all attributes, equivalent of --output-attribute ''.

Avoid using this flag in automation because it may be expensive to produce certain attributes, and because it makes harder to track which special attributes are used.
-B, --output-basic-attributes Output basic attributes, namely those the user can supply, plus rule type and package name
-a, --output-attribute <ATTRIBUTE> Regular expressions to match attributes. Regular expressions are used in "search" mode, so for example empty string matches all attributes including special attributes.

When using in automation, please specify the regular expression to match the attribute precisely, for example --output-attribute '^headers$' to make it easier to track which special attributes are used.
--output-attributes <ATTRIBUTE> Deprecated: Use --output-attribute instead.

List of space-separated attributes to output, --output-attributes attr1 attr2.
--json Output in JSON format
--dot Output in Graphviz Dot format
--dot-compact Output in a more compact format than Graphviz Dot
--output-format <dot|dot_compact|json|starlark> Output format (default: list).
```
       dot -  dot graph format.

       dot_compact - compact alternative to dot format.

       json - JSON format.

       starlark - targets are printed like starlark code that would produce them.
```
- Possible values:
  - dot
  - json
  - dot_compact
  - starlark
- --show-providers Show the providers of the query result instead of the attributes and labels
-u, --target-universe <TARGET_UNIVERSE> Comma separated list of targets to construct a configured target universe.

When the option is specified, command targets are be resolved in this universe. Additionally, --target-platforms= and --modifier= flags are be used to configure the universe targets, not the command targets.

This argument is particularly recommended on most non-trivial cqueries. In the absence of this argument, bsmr will use the target literals in your cquery expression as the value for this argument, which may not be what you want.
--target-platforms <PLATFORM> Configuration target (one) to use to configure targets
-m, --modifier <VALUE> A configuration modifier to configure all targets on the command line. This may be a constraint value target.
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none
- --profile-mode <PROFILE_MODE> Profile target loading.
When this option is enabled, Bsmr will profile every BUILD.bsmr file loaded during the query and merge the results into a single profile. The command may return cached profile data if BUILD.bsmr files were not invalidated.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none
- --profile-output <PROFILE_OUTPUT> Where to write profile output

`bsmr init`¶

Create .bsmr at your project root without replacing your language manifests.

Example:

bsmr init
bsmr build apps/api

An existing .bsmr is left unchanged.

Usage: bsmr init [OPTIONS] [PATH]

Arguments:¶

<PATH> The path to initialize the project in. The folder does not need to exist
- Default value: .

Common Options:¶

Common options are documented under Global options.

Options:¶

--no-prelude Don't include the standard prelude
--allow-dirty Initialize the project even if the git repo at [PATH] has uncommitted changes
--git Also initialize a git repository at the given path, and set up an appropriate .gitignore file

`bsmr expand-external-cell`¶

Expand the contents of an external cell into the repo.

The contents are placed at the path you specified for this cell in your bsmrconfig.

If you additionally remove the entry from the external_cells section of your bsmrconfig, you can edit the files directly in the repo and see those edits reflected in your build.

Note that this creates a point-in-time snapshot. The files in the repo will not be updated if you eg change the git commit of the cell in the future.

Usage: bsmr expand-external-cell [OPTIONS] [CELLS]...

Arguments:¶

<CELLS>

Common Options:¶

Common options are documented under Global options.

Options:¶

--all-cells Expand all cells that Bessemer knows about

`bsmr go`¶

Build Go package graphs with Bessemer

Usage: bsmr go <COMMAND>

Subcommands:¶

toolchain: Pin or verify the exact official Go SDK used by Bessemer
sync: Synchronize Go SDK metadata into generated Bessemer manifests

Common Options:¶

Common options are documented under Global options.

`bsmr go toolchain`¶

Pin or verify the exact official Go SDK used by Bessemer

Usage: bsmr go toolchain [OPTIONS]

Common Options:¶

Common options are documented under Global options.

Options:¶

--version <VERSION> Exact stable release to select and acquire
--update Update an existing lock to the latest stable release from go.dev
--check Verify the committed lock and generated toolchain without network access

`bsmr go sync`¶

Synchronize Go SDK metadata into generated Bessemer manifests

Usage: bsmr go sync [OPTIONS]

Common Options:¶

Common options are documented under Global options.

Options:¶

--check Verify generated manifests and their ownership index without changing files
--buildfile <BUILDFILE> Override the configured build-file name generated in each Go package
--tags <TAGS> Allowlisted build tags used for both SDK selection and action identity
--cgo Include cgo-selected files using the host-native C/C++ toolchain

`bsmr install`¶

Build and install an application

Usage: bsmr install [OPTIONS] [TARGET]... [-- <INSTALL_ARGS>...]

Arguments:¶

<TARGET> Target to build and install
<INSTALL_ARGS> Additional arguments passed to the install when running it

Common Options:¶

Common options are documented under Global options.

Options:¶

--installer-debug Prints installer output to stderr. It might break superconsole
-r, --run Run an Android activity. Here for compatibility with legacy - it is automatically forwarded to the installer
-e, --emulator Use this option to use emulators only on Android. Here for compatibility with legacy - it is automatically forwarded to the installer
-d, --device Use this option to use real devices only on Android. Here for compatibility with legacy - it is automatically forwarded to the installer
-s, --serial <SERIAL> Use Android device or emulator with specific serial or UDID number. Here for compatibility with legacy - it is automatically forwarded to the installer
-x, --all-devices Use all connected Android devices and/or emulators (multi-install mode). Here for compatibility with legacy - it is automatically forwarded to the installer
-a, --activity <ACTIVITY> Android activity to launch e.g. com.facebook/.LoginActivity. Implies -r. Here for compatibility with legacy - it is automatically forwarded to the installer
-i, --intent-uri <INTENT_URI> Android Intent URI to launch e.g. fb://profile. Implies -r. Here for compatibility with legacy - it is automatically forwarded to the installer
-w, --wait-for-debugger Have the launched Android process wait for the debugger. Here for compatibility with legacy - it is automatically forwarded to the installer
-u, --uninstall Use this option to uninstall an installed app before installing again. Here for compatibility with legacy - it is automatically forwarded to the installer
-k, --keep Use this option to Keep user data when uninstalling. Here for compatibility with legacy - it is automatically forwarded to the installer
--build-report <PATH> Print a build report

--build-report=- will print the build report to stdout --build-report=<filepath> will write the build report to the file
--enable-optional-validations <VALIDATION_NAMES> Comma separated list of validation names to run that are marked optional.

By default, validations marked as optional are skipped. This option overrides the behaviour and executes those validations.
--build-report-options <BUILD_REPORT_OPTIONS> Comma separated list of build report options.

The following options are supported:

fill-out-failures: fill out failures the same way Legacy would.

package-project-relative-paths: emit the project-relative path of packages for the targets that were built.

exclude-action-error-diagnostics: exclude error_diagnostics field from action errors in the build report.

truncate-error-content: truncate error content in the build report to reduce size.
--streaming-build-report <PATH> Stream intermediary build reports to a file in json lines format.

Each output materialization will trigger a new build report which will be written to the file as a single line json.
-j, --num-threads <THREADS> Number of threads to use during execution (default is # cores)
--sandbox Execute every action in a fresh networkless Firecracker microVM
--local-only Enable only local execution. Will reject actions that cannot execute locally
--remote-only Enable only remote execution. Will reject actions that cannot execute remotely
--prefer-local Enable hybrid execution. Will prefer executing actions that can execute locally on the local host
--prefer-remote Enable hybrid execution. Will prefer executing actions that can execute remotely on RE and will avoid racing local and remote execution
--unstable-no-execution Experimental: Disable all execution
--no-remote-cache Do not perform remote cache queries or cache writes. If remote execution is enabled, the RE service might still deduplicate actions, so for e.g. benchmarking, using a random isolation dir is preferred
--write-to-cache-anyway Could be used to enable the action cache writes on the RE worker when no_remote_cache is specified
--eager-dep-files Process dep files when they are generated (i.e. after running a command that produces dep files), rather than when they are used (i.e. before re-running a command that previously produced dep files). Use this when debugging commands that produce dep files. Note that commands that previously produced dep files will not re-run: only dep files produced during this command will be eagerly loaded
--upload-all-actions Uploads every action to the RE service, regardless of whether the action needs to execute on RE.

This is useful when debugging builds and trying to inspect actions which executed remotely. It's possible that the action result is cached but the action itself has expired. In this case, downloading the action itself would fail. Enabling this option would unconditionally upload all actions, thus you will not hit any expiration issues.
--fail-fast If Bsmr hits an error, do as little work as possible before exiting.

To illustrate the effect of this flag, consider an invocation of build :foo :bar. The default behavior of bsmr is to do enough work to get a result for the builds of each of :foo and :bar, and no more. This means that bsmr will continue to complete the build of :bar after the build of :foo has failed; however, once one dependency of :foo has failed, other dependencies will be cancelled unless they are needed by :bar.

This flag changes the behavior of bsmr to not wait on :bar to complete once :foo has failed. Generally, this flag only has an effect on builds that specify multiple targets.

--keep-going changes the behavior of bsmr to not only wait on :bar once one dependency of :foo has failed, but to additionally attempt to build other dependencies of :foo if possible.
--keep-going If Bsmr hits an error, continue doing as much work as possible before exiting.

See --fail-fast for more details.
--skip-missing-targets If target is missing, then skip building instead of throwing error
--skip-incompatible-targets If target is incompatible with the specified configuration, skip building instead of throwing error. This does not apply to targets specified with glob patterns /... or : which are skipped unconditionally
--materialize-failed-inputs Materializes inputs for failed actions which ran on RE
--materialize-failed-outputs Materializes outputs (if present) for failed actions which ran on RE
--target-platforms <PLATFORM> Configuration target (one) to use to configure targets
-m, --modifier <VALUE> A configuration modifier to configure all targets on the command line. This may be a constraint value target.
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr kill`¶

Kill the Bessemer daemon.

Note there's also bsmr killall and bsmr clean.

bsmr killall kills all the bsmr processes on the machine.

bsmr clean kills the bsmr daemon and also deletes the bsmr state files.

Usage: bsmr kill [OPTIONS]

Common Options:¶

Common options are documented under Global options.

`bsmr killall`¶

Kill all bsmr processes on the machine

Usage: bsmr killall [OPTIONS]

Common Options:¶

Common options are documented under Global options.

`bsmr root`¶

Find a Bessemer cell, project, or package root

Usage: bsmr root [OPTIONS]

Common Options:¶

Common options are documented under Global options.

Options:¶

-k, --kind <KIND> which root to print
- Default value: cell
- Possible values:
  - cell
  - project
  - daemon
- --dir <PATH> determine the root for a specific directory (if not provided, finds the root for the current directory)

`bsmr query`¶

Alias for uquery

Usage: bsmr query [OPTIONS] <QUERY> [QUERY_ARGS]...

Arguments:¶

<QUERY> the query to evaluate
<QUERY_ARGS> list of literals for a multi-query (one containing %s or %Ss)

Common Options:¶

Common options are documented under Global options.

Options:¶

-A, --output-all-attributes Output all attributes, equivalent of --output-attribute ''.

Avoid using this flag in automation because it may be expensive to produce certain attributes, and because it makes harder to track which special attributes are used.
-B, --output-basic-attributes Output basic attributes, namely those the user can supply, plus rule type and package name
-a, --output-attribute <ATTRIBUTE> Regular expressions to match attributes. Regular expressions are used in "search" mode, so for example empty string matches all attributes including special attributes.

When using in automation, please specify the regular expression to match the attribute precisely, for example --output-attribute '^headers$' to make it easier to track which special attributes are used.
--output-attributes <ATTRIBUTE> Deprecated: Use --output-attribute instead.

List of space-separated attributes to output, --output-attributes attr1 attr2.
--json Output in JSON format
--dot Output in Graphviz Dot format
--dot-compact Output in a more compact format than Graphviz Dot

--output-format <dot|dot_compact|json|starlark> Output format (default: list).

       dot -  dot graph format.

       dot_compact - compact alternative to dot format.

       json - JSON format.

       starlark - targets are printed like starlark code that would produce them.

Possible values:
- dot
- json
- dot_compact
- starlark
-m, --modifier <VALUE> This option is not used

--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr run`¶

Build and run the selected target.

Use -- to separate arguments to the target from arguments to bsmr:

bsmr run //my/target -- --arg1 --arg2

The Build ID for the underlying build execution is made available to the target in the BSMR_RUN_BUILD_ID environment variable.

Usage: bsmr bsmr run [OPTIONS] <TARGET> [-- <TARGET_ARGS>...]

Arguments:¶

<TARGET> Target to build and run
<TARGET_ARGS> Additional arguments passed to the target when running it

Common Options:¶

Common options are documented under Global options.

Options:¶

--command-args-file <COMMAND_ARGS_FILE> Write the command to a file instead of executing it.
--chdir <CHDIR> Set the current working directory of the executable being run
--emit-shell Instead of running the command, print out the command formatted for shell interpolation, use as: $(bsmr run --emit-shell ...)
--build-report <PATH> Print a build report

--build-report=- will print the build report to stdout --build-report=<filepath> will write the build report to the file
--enable-optional-validations <VALIDATION_NAMES> Comma separated list of validation names to run that are marked optional.

By default, validations marked as optional are skipped. This option overrides the behaviour and executes those validations.
--build-report-options <BUILD_REPORT_OPTIONS> Comma separated list of build report options.

The following options are supported:

fill-out-failures: fill out failures the same way Legacy would.

package-project-relative-paths: emit the project-relative path of packages for the targets that were built.

exclude-action-error-diagnostics: exclude error_diagnostics field from action errors in the build report.

truncate-error-content: truncate error content in the build report to reduce size.
--streaming-build-report <PATH> Stream intermediary build reports to a file in json lines format.

Each output materialization will trigger a new build report which will be written to the file as a single line json.
-j, --num-threads <THREADS> Number of threads to use during execution (default is # cores)
--sandbox Execute every action in a fresh networkless Firecracker microVM
--local-only Enable only local execution. Will reject actions that cannot execute locally
--remote-only Enable only remote execution. Will reject actions that cannot execute remotely
--prefer-local Enable hybrid execution. Will prefer executing actions that can execute locally on the local host
--prefer-remote Enable hybrid execution. Will prefer executing actions that can execute remotely on RE and will avoid racing local and remote execution
--unstable-no-execution Experimental: Disable all execution
--no-remote-cache Do not perform remote cache queries or cache writes. If remote execution is enabled, the RE service might still deduplicate actions, so for e.g. benchmarking, using a random isolation dir is preferred
--write-to-cache-anyway Could be used to enable the action cache writes on the RE worker when no_remote_cache is specified
--eager-dep-files Process dep files when they are generated (i.e. after running a command that produces dep files), rather than when they are used (i.e. before re-running a command that previously produced dep files). Use this when debugging commands that produce dep files. Note that commands that previously produced dep files will not re-run: only dep files produced during this command will be eagerly loaded
--upload-all-actions Uploads every action to the RE service, regardless of whether the action needs to execute on RE.

This is useful when debugging builds and trying to inspect actions which executed remotely. It's possible that the action result is cached but the action itself has expired. In this case, downloading the action itself would fail. Enabling this option would unconditionally upload all actions, thus you will not hit any expiration issues.
--fail-fast If Bsmr hits an error, do as little work as possible before exiting.

To illustrate the effect of this flag, consider an invocation of build :foo :bar. The default behavior of bsmr is to do enough work to get a result for the builds of each of :foo and :bar, and no more. This means that bsmr will continue to complete the build of :bar after the build of :foo has failed; however, once one dependency of :foo has failed, other dependencies will be cancelled unless they are needed by :bar.

This flag changes the behavior of bsmr to not wait on :bar to complete once :foo has failed. Generally, this flag only has an effect on builds that specify multiple targets.

--keep-going changes the behavior of bsmr to not only wait on :bar once one dependency of :foo has failed, but to additionally attempt to build other dependencies of :foo if possible.
--keep-going If Bsmr hits an error, continue doing as much work as possible before exiting.

See --fail-fast for more details.
--skip-missing-targets If target is missing, then skip building instead of throwing error
--skip-incompatible-targets If target is incompatible with the specified configuration, skip building instead of throwing error. This does not apply to targets specified with glob patterns /... or : which are skipped unconditionally
--materialize-failed-inputs Materializes inputs for failed actions which ran on RE
--materialize-failed-outputs Materializes outputs (if present) for failed actions which ran on RE
-u, --target-universe <TARGET_UNIVERSE> Comma separated list of targets to construct a configured target universe.

When the option is specified, command targets are be resolved in this universe. Additionally, --target-platforms= and --modifier= flags are be used to configure the universe targets, not the command targets.

This argument is particularly recommended on most non-trivial cqueries. In the absence of this argument, bsmr will use the target literals in your cquery expression as the value for this argument, which may not be what you want.
--target-platforms <PLATFORM> Configuration target (one) to use to configure targets
-m, --modifier <VALUE> A configuration modifier to configure all targets on the command line. This may be a constraint value target.
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr server`¶

Start, query, and control the bsmr server, a long-lived process, spanning bsmr command line invocations. Using this command can ensure the daemon is running.

To stop a specific server, use bsmr kill and add --isolation-dir for a specific instance. To stop all instances, use bsmr killall.

Usage: bsmr server [OPTIONS]

Common Options:¶

Common options are documented under Global options.

Options:¶

--status Print bsmrd status as JSON after ensuring the server is running.
--snapshot Whether to include a state snapshot in the JSON status output.

`bsmr status`¶

Show Bessemer daemon status

Usage: bsmr status [OPTIONS]

Common Options:¶

Common options are documented under Global options.

Options:¶

--snapshot Whether to include a state snapshot in the output.
--all Enable printing status for all running bsmrd
--include-tokio-runtime-metrics Enable printing metrics from the Tokio runtime

`bsmr starlark`¶

Run Starlark operations

Usage: bsmr starlark <COMMAND>

Subcommands:¶

lint: Run the Starlark linter.
typecheck: Run the Starlark typechecker.
debug-attach: Run the starlark debug adapter protocol server

Common Options:¶

Common options are documented under Global options.

`bsmr starlark lint`¶

Run the Starlark linter.

Usage: bsmr starlark lint [OPTIONS] <PATH>...

Arguments:¶

<PATH>

Common Options:¶

Common options are documented under Global options.

Options:¶

--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr starlark typecheck`¶

Run the Starlark typechecker.

Usage: bsmr starlark typecheck [OPTIONS] <PATH>...

Arguments:¶

<PATH>

Common Options:¶

Common options are documented under Global options.

Options:¶

--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr starlark debug-attach`¶

Run the starlark debug adapter protocol server

This forwards requests received on stdin to a debug server running in the bsmr daemon. DAP events and responses are returned from the daemon and sent to this command's stdout.

Usage: bsmr starlark debug-attach [OPTIONS]

Common Options:¶

Common options are documented under Global options.

Options:¶

--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr targets`¶

Alias for utargets

Usage: bsmr targets [OPTIONS] [TARGET_PATTERNS]...

Arguments:¶

<TARGET_PATTERNS> Patterns to interpret

Common Options:¶

Common options are documented under Global options.

Options:¶

--json Print targets as JSON
--json-lines Print targets as JSON-lines
--stats Print statistics of how many entries were processed
--resolve-alias Print the fully-qualified build target for the specified aliases
--show-target-hash Print a stable hash of each target after the target name
--show-unconfigured-target-hash Print a stable unconfigured hash of each target after the target name
--target-hash-file-mode <TARGET_HASH_FILE_MODE> Modifies computation of target hashes. If set to PATHS_AND_CONTENTS (the default), the contents of all files referenced from the targets will be used to compute the target hash. If set to PATHS_ONLY, only files' paths contribute to the hash. If set to NONE no files will be used. See also --target-hash-modified-paths
- Default value: paths_and_contents
- Possible values:
  - paths_only
  - paths_and_contents
  - none
- --target-hash-modified-paths <TARGET_HASH_MODIFIED_PATHS> Modifies computation of target hashes. Only effective when --target-hash-file-mode is set to PATHS_ONLY. If a target or its dependencies reference a file from this set, the target's hash will be different than if this option was omitted. Otherwise, the target's hash will be the same as if this option was omitted
--target-hash-function <TARGET_HASH_FUNCTION> Selects either the "fast" or the "strong" target hash function to be used for computing target hashes. While we don't specify the exact algorithm, the "strong" algorithm should be a reasonable cryptographic hash (ex. blake3) while the "fast" function will likely be a non-crypto hash. Both functions are guaranteed to be deterministic and to have the same value across different platforms/architectures
- Default value: fast
- Possible values:
  - sha1
  - sha256
  - murmur-hash3
  - fast
  - strong
- --target-hash-recursive <TARGET_HASH_RECURSIVE> When true, emit the hash or target node and all dependencies recursively. When false, hash only the target node
- Default value: false
- Possible values:
  - true
  - false
- -A, --output-all-attributes Output all attributes, equivalent of --output-attribute ''.
Avoid using this flag in automation because it may be expensive to produce certain attributes, and because it makes harder to track which special attributes are used.
-B, --output-basic-attributes Output basic attributes, namely those the user can supply, plus rule type and package name
-a, --output-attribute <ATTRIBUTE> Regular expressions to match attributes. Regular expressions are used in "search" mode, so for example empty string matches all attributes including special attributes.

When using in automation, please specify the regular expression to match the attribute precisely, for example --output-attribute '^headers$' to make it easier to track which special attributes are used.
--output-attributes <ATTRIBUTE> Deprecated: Use --output-attribute instead.

List of space-separated attributes to output, --output-attributes attr1 attr2.
--include-defaults Enables printing of default attributes. This would be attributes in a target that aren't explicitly set in the target but instead use the default set in the rule declaration
--show-output Print the path to the output for each of the rules relative to the project root
--show-full-output Print the absolute path to the output for each of the rules
--show-simple-output Print only the path to the output for each of the rules relative to the project root
--show-full-simple-output Print only the absolute path to the output for each of the rules
--show-json-output Print the output paths relative to the project root, in JSON format
--show-full-json-output Print the output absolute paths, in JSON format
--keep-going On loading errors, put bsmr.error in the output stream and continue
--streaming Write output as soon as it is available. The order of the output items is non-deterministic and if multiple patterns cover the same target, may have duplicates
--no-cache Don't cache the target information on the build graph
--imports Show the imports of each package/import. Shows an additional output per package/import (not per target), including implicit dependencies (e.g. the prelude) but only direct dependencies (not the transitive closure)
--package-values Show the package values. Produces an additional attribute representing all the package values for the package containing the target
--package-values-regex <VALUES> Regular expressions to match package values. Produces an additional attribute representing package values for the package containing the target. Regular expressions are used in "search" mode so, for example, empty string matches all package values
-o, --output <PATH> File to put the output in, rather than sending to stdout.

File will be created if it does not exist, and overwritten if it does.
--compression <SCHEME> Compress the output
- Default value: none
- Possible values:
  - none
  - gzip
  - zstd
- -j, --num-threads <THREADS> Number of threads to use during execution (default is # cores)
--target-platforms <PLATFORM> Configuration target (one) to use to configure targets
-m, --modifier <VALUE> A configuration modifier to configure all targets on the command line. This may be a constraint value target.
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr utargets`¶

Show details about the specified targets.

This command is meant to only handle unconfigured targets, but for historical reasons, with certain flags it can also work with configured targets.

Usage: bsmr utargets [OPTIONS] [TARGET_PATTERNS]...

Arguments:¶

<TARGET_PATTERNS> Patterns to interpret

Common Options:¶

Common options are documented under Global options.

Options:¶

--json Print targets as JSON
--json-lines Print targets as JSON-lines
--stats Print statistics of how many entries were processed
--resolve-alias Print the fully-qualified build target for the specified aliases
--show-target-hash Print a stable hash of each target after the target name
--show-unconfigured-target-hash Print a stable unconfigured hash of each target after the target name
--target-hash-file-mode <TARGET_HASH_FILE_MODE> Modifies computation of target hashes. If set to PATHS_AND_CONTENTS (the default), the contents of all files referenced from the targets will be used to compute the target hash. If set to PATHS_ONLY, only files' paths contribute to the hash. If set to NONE no files will be used. See also --target-hash-modified-paths
- Default value: paths_and_contents
- Possible values:
  - paths_only
  - paths_and_contents
  - none
- --target-hash-modified-paths <TARGET_HASH_MODIFIED_PATHS> Modifies computation of target hashes. Only effective when --target-hash-file-mode is set to PATHS_ONLY. If a target or its dependencies reference a file from this set, the target's hash will be different than if this option was omitted. Otherwise, the target's hash will be the same as if this option was omitted
--target-hash-function <TARGET_HASH_FUNCTION> Selects either the "fast" or the "strong" target hash function to be used for computing target hashes. While we don't specify the exact algorithm, the "strong" algorithm should be a reasonable cryptographic hash (ex. blake3) while the "fast" function will likely be a non-crypto hash. Both functions are guaranteed to be deterministic and to have the same value across different platforms/architectures
- Default value: fast
- Possible values:
  - sha1
  - sha256
  - murmur-hash3
  - fast
  - strong
- --target-hash-recursive <TARGET_HASH_RECURSIVE> When true, emit the hash or target node and all dependencies recursively. When false, hash only the target node
- Default value: false
- Possible values:
  - true
  - false
- -A, --output-all-attributes Output all attributes, equivalent of --output-attribute ''.
Avoid using this flag in automation because it may be expensive to produce certain attributes, and because it makes harder to track which special attributes are used.
-B, --output-basic-attributes Output basic attributes, namely those the user can supply, plus rule type and package name
-a, --output-attribute <ATTRIBUTE> Regular expressions to match attributes. Regular expressions are used in "search" mode, so for example empty string matches all attributes including special attributes.

When using in automation, please specify the regular expression to match the attribute precisely, for example --output-attribute '^headers$' to make it easier to track which special attributes are used.
--output-attributes <ATTRIBUTE> Deprecated: Use --output-attribute instead.

List of space-separated attributes to output, --output-attributes attr1 attr2.
--include-defaults Enables printing of default attributes. This would be attributes in a target that aren't explicitly set in the target but instead use the default set in the rule declaration
--show-output Print the path to the output for each of the rules relative to the project root
--show-full-output Print the absolute path to the output for each of the rules
--show-simple-output Print only the path to the output for each of the rules relative to the project root
--show-full-simple-output Print only the absolute path to the output for each of the rules
--show-json-output Print the output paths relative to the project root, in JSON format
--show-full-json-output Print the output absolute paths, in JSON format
--keep-going On loading errors, put bsmr.error in the output stream and continue
--streaming Write output as soon as it is available. The order of the output items is non-deterministic and if multiple patterns cover the same target, may have duplicates
--no-cache Don't cache the target information on the build graph
--imports Show the imports of each package/import. Shows an additional output per package/import (not per target), including implicit dependencies (e.g. the prelude) but only direct dependencies (not the transitive closure)
--package-values Show the package values. Produces an additional attribute representing all the package values for the package containing the target
--package-values-regex <VALUES> Regular expressions to match package values. Produces an additional attribute representing package values for the package containing the target. Regular expressions are used in "search" mode so, for example, empty string matches all package values
-o, --output <PATH> File to put the output in, rather than sending to stdout.

File will be created if it does not exist, and overwritten if it does.
--compression <SCHEME> Compress the output
- Default value: none
- Possible values:
  - none
  - gzip
  - zstd
- -j, --num-threads <THREADS> Number of threads to use during execution (default is # cores)
--target-platforms <PLATFORM> Configuration target (one) to use to configure targets
-m, --modifier <VALUE> A configuration modifier to configure all targets on the command line. This may be a constraint value target.
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr ctargets`¶

Resolve target patterns to configured targets

Usage: bsmr ctargets [OPTIONS] [TARGET_PATTERNS]...

Arguments:¶

<TARGET_PATTERNS> Patterns to interpret

Common Options:¶

Common options are documented under Global options.

Options:¶

--json Print targets as JSON
--json-report Print compatible targets and valid incompatible targets as JSON
--skip-missing-targets Skip missing targets from BUILD.bsmr files when non-glob pattern is specified. This option does not skip missing packages and does not ignore errors of BUILD.bsmr file evaluation
--keep-going On errors, put bsmr.error in the output stream and continue
-A, --output-all-attributes Output all attributes, equivalent of --output-attribute ''.

Avoid using this flag in automation because it may be expensive to produce certain attributes, and because it makes harder to track which special attributes are used.
-B, --output-basic-attributes Output basic attributes, namely those the user can supply, plus rule type and package name
-a, --output-attribute <ATTRIBUTE> Regular expressions to match attributes. Regular expressions are used in "search" mode, so for example empty string matches all attributes including special attributes.

When using in automation, please specify the regular expression to match the attribute precisely, for example --output-attribute '^headers$' to make it easier to track which special attributes are used.
--output-attributes <ATTRIBUTE> Deprecated: Use --output-attribute instead.

List of space-separated attributes to output, --output-attributes attr1 attr2.
--target-platforms <PLATFORM> Configuration target (one) to use to configure targets
-m, --modifier <VALUE> A configuration modifier to configure all targets on the command line. This may be a constraint value target.
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr uquery`¶

Perform queries on the unconfigured target graph

The unconfigured target graph consists of the targets as they are defined in the build files. In this graph, each target appears exactly once and select()s are in the unresolved form. For large queries, the unconfigured graph may be much smaller than the configured graph and queries can be much more efficiently performed there.

When querying the unconfigured graph, dependencies appearing in all branches of select() dictionaries will be treated as dependencies.

Run bsmr docs uquery or https://oss.dedaluslabs.ai/bsmr/users/query/uquery/ for more documentation about the functions available in uquery expressions.

Examples:

Print all the attributes of a target

`bsmr uquery //java/com/example/app:amazing --output-all-attributes

List the deps of a target (special characters in a target will require quotes): bsmr uquery 'deps("//java/com/example/app:amazing+more")'

select() encoding:

When printed, values with select()s use a special json encoding.

1 + select({"//:a": 1, "DEFAULT": 2}) will be encoded as:

{"//:a": 1, "DEFAULT": 2}}]}

Usage: bsmr uquery [OPTIONS] <QUERY> [QUERY_ARGS]...

Arguments:¶

<QUERY> the query to evaluate
<QUERY_ARGS> list of literals for a multi-query (one containing %s or %Ss)

Common Options:¶

Common options are documented under Global options.

Options:¶

-A, --output-all-attributes Output all attributes, equivalent of --output-attribute ''.

Avoid using this flag in automation because it may be expensive to produce certain attributes, and because it makes harder to track which special attributes are used.
-B, --output-basic-attributes Output basic attributes, namely those the user can supply, plus rule type and package name
-a, --output-attribute <ATTRIBUTE> Regular expressions to match attributes. Regular expressions are used in "search" mode, so for example empty string matches all attributes including special attributes.

When using in automation, please specify the regular expression to match the attribute precisely, for example --output-attribute '^headers$' to make it easier to track which special attributes are used.
--output-attributes <ATTRIBUTE> Deprecated: Use --output-attribute instead.

List of space-separated attributes to output, --output-attributes attr1 attr2.
--json Output in JSON format
--dot Output in Graphviz Dot format
--dot-compact Output in a more compact format than Graphviz Dot

--output-format <dot|dot_compact|json|starlark> Output format (default: list).

       dot -  dot graph format.

       dot_compact - compact alternative to dot format.

       json - JSON format.

       starlark - targets are printed like starlark code that would produce them.

Possible values:
- dot
- json
- dot_compact
- starlark
-m, --modifier <VALUE> This option is not used

--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr completion`¶

Print completion configuration for shell

For a one-time setup, run the one of the following commands appropriate for the shell you're using: - source <(bsmr completion bash) - source <(bsmr completion zsh) - source (bsmr completion fish | psub)

Usage: bsmr completion <SHELL>

Arguments:¶

<SHELL> shell for which to generate completion script
- Possible values:
  - bash
  - fish
  - zsh

Common Options:¶

Common options are documented under Global options.

`bsmr docs`¶

Print documentation of specified symbols

Usage: bsmr docs <COMMAND>

Subcommands:¶

starlark: Print documentation of user-defined starlark symbols
starlark-builtins: Generate documentation for starlark builtins
uquery: Print documentation for query/uquery
cquery: Print documentation for cquery
aquery: Print documentation for aquery
markdown-help-doc: Print out the bsmr subcommand markdown docs

Common Options:¶

Common options are documented under Global options.

`bsmr docs starlark`¶

Print documentation of user-defined starlark symbols

Usage: bsmr docs starlark [OPTIONS] [SYMBOL_PATTERNS]...

Arguments:¶

<SYMBOL_PATTERNS> Patterns to interpret. //foo:bar.bzl is 'every symbol in //foo:bar.bzl', //foo:bar.bzl:baz only returns the documentation for the symbol 'baz' in //foo:bar.bzl

Common Options:¶

Common options are documented under Global options.

Options:¶

--output-dir <OUTPUT_DIR> Directory to write markdown files to. Required if format is markdown_files.
--format <FORMAT> how to format the returned documentation
- Default value: json
- Possible values:
  - json
  - markdown_files
- --disable-starlark-types Disable runtime type checking in Starlark interpreter.
This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr docs starlark-builtins`¶

Generate documentation for starlark builtins.

This command is designed to support bsmr's doc generation and does not have stable output.

Usage: bsmr docs starlark-builtins [OPTIONS] --output-dir <OUTPUT_DIR>

Common Options:¶

Common options are documented under Global options.

Options:¶

--output-dir <OUTPUT_DIR> The directory to output files to
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr docs uquery`¶

Print documentation for query/uquery

Usage: bsmr docs uquery [OPTIONS]

Common Options:¶

Common options are documented under Global options.

Options:¶

--format <FORMAT> How to format the documentation
- Default value: rendered
- Possible values:
  - markdown
  - rendered

`bsmr docs cquery`¶

Print documentation for cquery

Usage: bsmr docs cquery [OPTIONS]

Common Options:¶

Common options are documented under Global options.

Options:¶

--format <FORMAT> How to format the documentation
- Default value: rendered
- Possible values:
  - markdown
  - rendered

`bsmr docs aquery`¶

Print documentation for aquery

Usage: bsmr docs aquery [OPTIONS]

Common Options:¶

Common options are documented under Global options.

Options:¶

--format <FORMAT> How to format the documentation
- Default value: rendered
- Possible values:
  - markdown
  - rendered

`bsmr docs markdown-help-doc`¶

Print out the bsmr subcommand markdown docs

Usage: bsmr docs markdown-help-doc <SUB_COMMAND>

Arguments:¶

<SUB_COMMAND> The bsmr sub command we want to generate the markdown doc

Common Options:¶

Common options are documented under Global options.

`bsmr profile`¶

Run starlark profiler

Usage: bsmr profile <COMMAND>

Subcommands:¶

analysis: Profile analysis
loading: Profile BUILD.bsmr file evaluation
bxl: Profile BXL script

Common Options:¶

Common options are documented under Global options.

`bsmr profile analysis`¶

Profile analysis

Usage: bsmr profile analysis [OPTIONS] --output <PATH> --mode <MODE> [TARGET_PATTERNS]...

Arguments:¶

<TARGET_PATTERNS>

Common Options:¶

Common options are documented under Global options.

Options:¶

-r, --recursive In analysis profiling, capture the profile of the target and its dependencies, and output the merged profile
-o, --output <PATH> Output file path for profile data.

File will be created if it does not exist, and overwritten if it does.
--mode <MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heap after analysis complete. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none
- -u, --target-universe <TARGET_UNIVERSE> Comma separated list of targets to construct a configured target universe.
When the option is specified, command targets are be resolved in this universe. Additionally, --target-platforms= and --modifier= flags are be used to configure the universe targets, not the command targets.

This argument is particularly recommended on most non-trivial cqueries. In the absence of this argument, bsmr will use the target literals in your cquery expression as the value for this argument, which may not be what you want.
--target-platforms <PLATFORM> Configuration target (one) to use to configure targets
-m, --modifier <VALUE> A configuration modifier to configure all targets on the command line. This may be a constraint value target.
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr profile loading`¶

Profile BUILD.bsmr file evaluation

Usage: bsmr profile loading [OPTIONS] --output <PATH> --mode <MODE> [TARGET_PATTERNS]...

Arguments:¶

<TARGET_PATTERNS>

Common Options:¶

Common options are documented under Global options.

Options:¶

-r, --recursive In analysis profiling, capture the profile of the target and its dependencies, and output the merged profile
-o, --output <PATH> Output file path for profile data.

File will be created if it does not exist, and overwritten if it does.
--mode <MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heap after analysis complete. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none
- -u, --target-universe <TARGET_UNIVERSE> Comma separated list of targets to construct a configured target universe.
When the option is specified, command targets are be resolved in this universe. Additionally, --target-platforms= and --modifier= flags are be used to configure the universe targets, not the command targets.

This argument is particularly recommended on most non-trivial cqueries. In the absence of this argument, bsmr will use the target literals in your cquery expression as the value for this argument, which may not be what you want.
--target-platforms <PLATFORM> Configuration target (one) to use to configure targets
-m, --modifier <VALUE> A configuration modifier to configure all targets on the command line. This may be a constraint value target.
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr profile bxl`¶

Profile BXL script

Usage: bsmr profile bxl [OPTIONS] --output <PATH> --mode <MODE> <BXL label> [-- <BXL INPUT ARGS>...]

Arguments:¶

<BXL label> The bxl function to execute as defined by the label of form <cell>//path/file.bxl:<function>
<BXL INPUT ARGS> Arguments passed to the bxl script

Common Options:¶

Common options are documented under Global options.

Options:¶

-M, --materializations <MATERIALIZATIONS> Materialize (or skip) the final artifacts, bypassing bsmrconfig.
- Possible values:
  - all
  - none
- --upload-final-artifacts <UPLOAD_FINAL_ARTIFACTS> Upload (or skip) the final artifacts.
- Possible values:
  - always
  - never
- --user-event-log <PATH> Write user events to this log file. Both user and internal events are written to main event log. If this flag is specified, user events are additionally written to user event log. Log format is JSONL, uncompressed if no known extensions are detected, or you can explicitly specify the compression via the file extension (ex: .json-lines.gz would be gzip compressed, .json-lines.zst would be zstd compressed). Resulting log is compatible with bsmr log show-user
--build-report <PATH> Print a build report

--build-report=- will print the build report to stdout --build-report=<filepath> will write the build report to the file
--enable-optional-validations <VALIDATION_NAMES> Comma separated list of validation names to run that are marked optional.

By default, validations marked as optional are skipped. This option overrides the behaviour and executes those validations.
--build-report-options <BUILD_REPORT_OPTIONS> Comma separated list of build report options.

The following options are supported:

fill-out-failures: fill out failures the same way Legacy would.

package-project-relative-paths: emit the project-relative path of packages for the targets that were built.

exclude-action-error-diagnostics: exclude error_diagnostics field from action errors in the build report.

truncate-error-content: truncate error content in the build report to reduce size.
--streaming-build-report <PATH> Stream intermediary build reports to a file in json lines format.

Each output materialization will trigger a new build report which will be written to the file as a single line json.
-j, --num-threads <THREADS> Number of threads to use during execution (default is # cores)
--sandbox Execute every action in a fresh networkless Firecracker microVM
--local-only Enable only local execution. Will reject actions that cannot execute locally
--remote-only Enable only remote execution. Will reject actions that cannot execute remotely
--prefer-local Enable hybrid execution. Will prefer executing actions that can execute locally on the local host
--prefer-remote Enable hybrid execution. Will prefer executing actions that can execute remotely on RE and will avoid racing local and remote execution
--unstable-no-execution Experimental: Disable all execution
--no-remote-cache Do not perform remote cache queries or cache writes. If remote execution is enabled, the RE service might still deduplicate actions, so for e.g. benchmarking, using a random isolation dir is preferred
--write-to-cache-anyway Could be used to enable the action cache writes on the RE worker when no_remote_cache is specified
--eager-dep-files Process dep files when they are generated (i.e. after running a command that produces dep files), rather than when they are used (i.e. before re-running a command that previously produced dep files). Use this when debugging commands that produce dep files. Note that commands that previously produced dep files will not re-run: only dep files produced during this command will be eagerly loaded
--upload-all-actions Uploads every action to the RE service, regardless of whether the action needs to execute on RE.

This is useful when debugging builds and trying to inspect actions which executed remotely. It's possible that the action result is cached but the action itself has expired. In this case, downloading the action itself would fail. Enabling this option would unconditionally upload all actions, thus you will not hit any expiration issues.
--fail-fast If Bsmr hits an error, do as little work as possible before exiting.

To illustrate the effect of this flag, consider an invocation of build :foo :bar. The default behavior of bsmr is to do enough work to get a result for the builds of each of :foo and :bar, and no more. This means that bsmr will continue to complete the build of :bar after the build of :foo has failed; however, once one dependency of :foo has failed, other dependencies will be cancelled unless they are needed by :bar.

This flag changes the behavior of bsmr to not wait on :bar to complete once :foo has failed. Generally, this flag only has an effect on builds that specify multiple targets.

--keep-going changes the behavior of bsmr to not only wait on :bar once one dependency of :foo has failed, but to additionally attempt to build other dependencies of :foo if possible.
--keep-going If Bsmr hits an error, continue doing as much work as possible before exiting.

See --fail-fast for more details.
--skip-missing-targets If target is missing, then skip building instead of throwing error
--skip-incompatible-targets If target is incompatible with the specified configuration, skip building instead of throwing error. This does not apply to targets specified with glob patterns /... or : which are skipped unconditionally
--materialize-failed-inputs Materializes inputs for failed actions which ran on RE
--materialize-failed-outputs Materializes outputs (if present) for failed actions which ran on RE
-o, --output <PATH> Output file path for profile data.

File will be created if it does not exist, and overwritten if it does.
--mode <MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heap after analysis complete. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none
- -u, --target-universe <TARGET_UNIVERSE> Comma separated list of targets to construct a configured target universe.
When the option is specified, command targets are be resolved in this universe. Additionally, --target-platforms= and --modifier= flags are be used to configure the universe targets, not the command targets.

This argument is particularly recommended on most non-trivial cqueries. In the absence of this argument, bsmr will use the target literals in your cquery expression as the value for this argument, which may not be what you want.
--target-platforms <PLATFORM> Configuration target (one) to use to configure targets
-m, --modifier <VALUE> A configuration modifier to configure all targets on the command line. This may be a constraint value target.
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr clean`¶

Delete generated files and caches.

The command also kills the bsmr daemon.

Usage: bsmr clean [OPTIONS]

Common Options:¶

Common options are documented under Global options.

Options:¶

--dry-run Performs a dry-run and prints the paths that would be removed.
--stale <DURATION> Delete artifacts from bsmr-out older than 1 week or older than the specified duration, without killing the daemon
--tracked-only Only considers tracked artifacts for cleanup.

bsmr-out can contain untracked artifacts for different reasons: - Outputs from aborted actions - State getting deleted (e.g., new bsmrversion that changes the on-disk state format) - Writing to bsmr-out without being expected by Bsmr
--adaptive-low-disk-threshold <PERCENT> Enable adaptive low-disk promotion: after the regular stale scan, promote retained, non-active artifacts (oldest-access first) to stale until projected free disk % rises above this threshold (0.0 - 100.0)
--adaptive-min-ttl <DURATION> Minimum TTL floor for adaptive low-disk promotion: retained artifacts accessed within this duration of now are never promoted, even under disk pressure. Ignored unless --adaptive-low-disk-threshold is set
- Default value: 12h
- --background Run the clean operation in the background
-m, --modifier <VALUE> This option is not used
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

`bsmr log`¶

Commands for interacting with bsmr logs

Usage: bsmr log <COMMAND>

Subcommands:¶

what-ran: Output everything that bsmr ran from the selected invocation. If no invocation was specified, use the last bsmr invocation from this isolation directory
what-failed: Outputs every command that failed in the selected invocation
path: Output the path to the selected log
show: Outputs the log in JSON format from selected invocation
cmd: Show bsmr command line arguments from selected invocation
what-up: Show the spans that were open when the log ended
what-materialized: Outputs materializations from selected invocation
what-uploaded: Outputs stats about uploads to RE from the selected invocation
critical-path: Show the critical path for a selected build
slowest-path: Show the slowest path for a selected build
replay: Replay an event log
show-user: Converts the event log from a selected invocation into a user event log, in JSONL format
summary: Outputs high level statistics about the build
diff: Subcommands for diff'ing two bsmr commands
external-configs: Display the values and origins of external configs for a selected command
chrome-trace: Generates a Chrome trace from a bsmr event log

Common Options:¶

Common options are documented under Global options.

`bsmr log what-ran`¶

Output everything that bsmr ran from the selected invocation. If no invocation was specified, use the last bsmr invocation from this isolation directory.

The output is presented as a series of tab-delimited records with the following structure:

build upstream//your:target local clang foo.c

1: The reason for executing a given command. That's either to build or to test.

2: The identity of this command. This will include the target that required it.

3: The executor for this command. This will either be RE or local.

4: Details to reproduce it. For RE, that's the action digest. For local, the command.

To reproduce an action that ran on RE, use the following command then follow the instructions. The DIGEST is of the form hash:size.

$ frecli cas download-action DIGEST

To reproduce an action that ran locally, make sure your working directory is the project root (if unsure, use bsmr root --kind project to find it), then run the command. The command is already shell-quoted.

Usage: bsmr log what-ran [OPTIONS] [PATH]

Arguments:¶

<PATH> A path to an event-log file to read from

Common Options:¶

Common options are documented under Global options.

Options:¶

--recent <NUMBER> Open the event-log file from a recent command
--trace-id <ID> Show log by trace id
--no-remote Do not download the log if it is not found locally
--format <FORMAT> Which output format to use for this command
- Default value: readable
- Possible values:
  - readable: Human-readable output (default)
  - tabulated: Tab-delimited output. Deprecated in favor of readable
  - json: JSON format, one object per line
  - csv: Comma-separated values (CSV) format
- --emit-cache-queries
--skip-cache-hits
--skip-remote-executions
--skip-local-executions
--filter-category <FILTER_CATEGORY> Regular expression to filter commands by given action category (i.e. type of actions that are similar but operate on different inputs, such as invocations of a C++ compiler (whose category would be cxx_compile)). Matches by full string
--failed Show only commands that failed
--incomplete Show only commands that were not completed. That is command were running if bsmr process was killed, or command currently running if bsmr is running build now
--show-std-err Show also std_err from commands that are run. If the command fails before completing, we display "<command did not finish executing>". If it finishes but there is no error, we display "<stderr is empty>". Otherwise, std_err is shown. For JSON, we show raw values and null for non-completion
--omit-empty-std-err Omit commands if their std_err is empty

`bsmr log what-failed`¶

Outputs every command that failed in the selected invocation.

Look at the help for what-ran to understand the output format.

Usage: bsmr log what-failed [OPTIONS] [PATH]

Arguments:¶

<PATH> A path to an event-log file to read from

Common Options:¶

Common options are documented under Global options.

Options:¶

--recent <NUMBER> Open the event-log file from a recent command
--trace-id <ID> Show log by trace id
--no-remote Do not download the log if it is not found locally
--format <FORMAT> Which output format to use for this command
- Default value: readable
- Possible values:
  - readable: Human-readable output (default)
  - tabulated: Tab-delimited output. Deprecated in favor of readable
  - json: JSON format, one object per line
  - csv: Comma-separated values (CSV) format
- --emit-cache-queries
--skip-cache-hits
--skip-remote-executions
--skip-local-executions
--filter-category <FILTER_CATEGORY> Regular expression to filter commands by given action category (i.e. type of actions that are similar but operate on different inputs, such as invocations of a C++ compiler (whose category would be cxx_compile)). Matches by full string

`bsmr log path`¶

Output the path to the selected log

Usage: bsmr log path [OPTIONS] [PATH]

Arguments:¶

<PATH> A path to an event-log file to read from

Common Options:¶

Common options are documented under Global options.

Options:¶

--recent <NUMBER> Open the event-log file from a recent command
--trace-id <ID> Show log by trace id
--no-remote Do not download the log if it is not found locally
--all List all the logs

`bsmr log show`¶

Outputs the log in JSON format from selected invocation

Usage: bsmr log show [OPTIONS] [PATH]

Arguments:¶

<PATH> A path to an event-log file to read from

Common Options:¶

Common options are documented under Global options.

Options:¶

--recent <NUMBER> Open the event-log file from a recent command
--trace-id <ID> Show log by trace id
--no-remote Do not download the log if it is not found locally

`bsmr log cmd`¶

Show bsmr command line arguments from selected invocation.

This command output is not machine readable. Robots, please use bsmr log show.

Usage: bsmr log cmd [OPTIONS] [PATH]

Arguments:¶

<PATH> A path to an event-log file to read from

Common Options:¶

Common options are documented under Global options.

Options:¶

--recent <NUMBER> Open the event-log file from a recent command
--trace-id <ID> Show log by trace id
--no-remote Do not download the log if it is not found locally
--expand Show @-expanded command line arguments instead of the original command line

`bsmr log what-up`¶

Show the spans that were open when the log ended

Usage: bsmr log what-up [OPTIONS] [PATH]

Arguments:¶

<PATH> A path to an event-log file to read from

Common Options:¶

Common options are documented under Global options.

Options:¶

--recent <NUMBER> Open the event-log file from a recent command
--trace-id <ID> Show log by trace id
--no-remote Do not download the log if it is not found locally
--after <NUMBER> Print the actions that where open after certain amount of milliseconds

`bsmr log what-materialized`¶

Outputs materializations from selected invocation.

The output is a tab-separated list containing the path, the materialization method, the file count, and the total size (after decompression).

Usage: bsmr log what-materialized [OPTIONS] [PATH]

Arguments:¶

<PATH> A path to an event-log file to read from

Common Options:¶

Common options are documented under Global options.

Options:¶

--recent <NUMBER> Open the event-log file from a recent command
--trace-id <ID> Show log by trace id
--no-remote Do not download the log if it is not found locally
-s, --sort-by-size Sort the output by total bytes in ascending order
--aggregate-by-ext Aggregates the output by file extension
--format <FORMAT> Which output format to use for this command
- Default value: readable
- Possible values:
  - readable: Human-readable output (default)
  - tabulated: Tab-delimited output. Deprecated in favor of readable
  - json: JSON format, one object per line
  - csv: Comma-separated values (CSV) format

`bsmr log what-uploaded`¶

Outputs stats about uploads to RE from the selected invocation

Usage: bsmr log what-uploaded [OPTIONS] [PATH]

Arguments:¶

<PATH> A path to an event-log file to read from

Common Options:¶

Common options are documented under Global options.

Options:¶

--recent <NUMBER> Open the event-log file from a recent command
--trace-id <ID> Show log by trace id
--no-remote Do not download the log if it is not found locally
--format <FORMAT> Which output format to use for this command
- Default value: readable
- Possible values:
  - readable: Human-readable output (default)
  - tabulated: Tab-delimited output. Deprecated in favor of readable
  - json: JSON format, one object per line
  - csv: Comma-separated values (CSV) format
- --aggregate-by-ext Aggregates the output by file extension

`bsmr log critical-path`¶

Show the critical path for a selected build.

This produces output listing every node on the critical path.

It includes the kind of node, its name, category and identifier, as well as total duration (runtime of this node), user duration (duration the user can improve), potential improvement before this node stops being on the critical path, non-critical path time, and start offset.

The readable format produces space-aligned columnar output with a header: <start_offset> <total> <waiting> <user> <potential> <kind> <name> <category> <identifier> <execution_kind>

The tabulated format produces tab-delimited output: <kind>\t<name>\t<category>\t<identifier>\t<execution_kind>\t<total_duration>\t<user_duration>\t<potential_improvement_duration>\t<non_critical_path_time>\t<start_offset>

All durations are in microseconds. Start offset is in microseconds from the beginning of the build.

Usage: bsmr log critical-path [OPTIONS] [PATH]

Arguments:¶

<PATH> A path to an event-log file to read from

Common Options:¶

Common options are documented under Global options.

Options:¶

--recent <NUMBER> Open the event-log file from a recent command
--trace-id <ID> Show log by trace id
--no-remote Do not download the log if it is not found locally
--format <FORMAT> Which output format to use for this command
- Default value: readable
- Possible values:
  - readable: Human-readable output (default)
  - tabulated: Tab-delimited output. Deprecated in favor of readable
  - json: JSON format, one object per line
  - csv: Comma-separated values (CSV) format

`bsmr log slowest-path`¶

Show the slowest path for a selected build.

While the critical path represents something closer to the "ideal" build time, the slowest path gives a better idea of what the build actually spends its time on. This can better highlight build overhead.

This produces output listing every node on the slowest path.

It includes the kind of node, its name, category and identifier, as well as total duration (runtime of this node), user duration (duration the user can improve), non-critical time, and start offset.

The readable format produces space-aligned columnar output with a header: <start_offset> <total> <waiting> <user> <potential> <kind> <name> <category> <identifier> <execution_kind>

The tabulated format produces tab-delimited output: <kind>\t<name>\t<category>\t<identifier>\t<execution_kind>\t<total_duration>\t<user_duration>\t<potential_improvement_duration>\t<non_critical_path_time>\t<start_offset>

All durations are in microseconds. Start offset is in microseconds from the beginning of the build.

Note that this prints a "potential improvement" just like log critical-path, but for slowest paths it's not computed.

Usage: bsmr log slowest-path [OPTIONS] [PATH]

Arguments:¶

<PATH> A path to an event-log file to read from

Common Options:¶

Common options are documented under Global options.

Options:¶

--recent <NUMBER> Open the event-log file from a recent command
--trace-id <ID> Show log by trace id
--no-remote Do not download the log if it is not found locally
--format <FORMAT> Which output format to use for this command
- Default value: readable
- Possible values:
  - readable: Human-readable output (default)
  - tabulated: Tab-delimited output. Deprecated in favor of readable
  - json: JSON format, one object per line
  - csv: Comma-separated values (CSV) format

`bsmr log replay`¶

Replay an event log.

This command allows visualizing an existing event log in a Superconsole.

Usage: bsmr log replay [OPTIONS] [PATH]

Arguments:¶

<PATH> A path to an event-log file to read from

Common Options:¶

Common options are documented under Global options.

Options:¶

--recent <NUMBER> Open the event-log file from a recent command
--trace-id <ID> Show log by trace id
--no-remote Do not download the log if it is not found locally
--speed <NUMBER> Control the playback speed using a float (i.e. 0.5, 2, etc)
- Default value: 1.0
- --seek <SEEK> Skip to the given number of seconds after the start of the command before starting the replay
--seek-absolute <SEEK_ABSOLUTE> Skip to the given unixtime number of seconds (floating point) or nanoseconds (integral) before starting the replay
--preload Preload the event log. This is typically only useful for benchmarking
--start-paused Start the replay in a paused state, press 'y' to resume

`bsmr log show-user`¶

Converts the event log from a selected invocation into a user event log, in JSONL format

Usage: bsmr log show-user [OPTIONS] [PATH]

Arguments:¶

<PATH> A path to an event-log file to read from

Common Options:¶

Common options are documented under Global options.

Options:¶

--recent <NUMBER> Open the event-log file from a recent command
--trace-id <ID> Show log by trace id
--no-remote Do not download the log if it is not found locally

`bsmr log summary`¶

Outputs high level statistics about the build

Usage: bsmr log summary [OPTIONS] [PATH]

Arguments:¶

<PATH> A path to an event-log file to read from

Common Options:¶

Common options are documented under Global options.

Options:¶

--recent <NUMBER> Open the event-log file from a recent command
--trace-id <ID> Show log by trace id
--no-remote Do not download the log if it is not found locally

`bsmr log diff`¶

Subcommands for diff'ing two bsmr commands

Usage: bsmr log diff <COMMAND>

Subcommands:¶

action-divergence: Identifies the first divergent action between two builds. Divergence is identified by the same action having differing outputs. Useful for identifying non-determinism
external-configs: Identifies the diff between external bsmrconfigs between two commands

Common Options:¶

Common options are documented under Global options.

`bsmr log diff action-divergence`¶

Identifies the first divergent action between two builds. Divergence is identified by the same action having differing outputs. Useful for identifying non-determinism

Usage: bsmr log diff action-divergence <--path1 <PATH1>|--trace-id1 <TRACE_ID1>|--recent1 <NUMBER>> <--path2 <PATH2>|--trace-id2 <TRACE_ID2>|--recent2 <NUMBER>>

Common Options:¶

Common options are documented under Global options.

Options:¶

--path1 <PATH1> A path to an event-log file of the first command
--trace-id1 <TRACE_ID1> Trace id of the first command
--recent1 <NUMBER> Open the event-log file from a recent command for the first command
--path2 <PATH2> A path to an event-log file of the second command
--trace-id2 <TRACE_ID2> Trace id of the second command
--recent2 <NUMBER> Open the event-log file from a recent command for the second command

`bsmr log diff external-configs`¶

Identifies the diff between external bsmrconfigs between two commands

Usage: bsmr log diff external-configs [OPTIONS] <--path1 <PATH1>|--trace-id1 <TRACE_ID1>|--recent1 <NUMBER>> <--path2 <PATH2>|--trace-id2 <TRACE_ID2>|--recent2 <NUMBER>>

Common Options:¶

Common options are documented under Global options.

Options:¶

--path1 <PATH1> A path to an event-log file of the first command
--trace-id1 <TRACE_ID1> Trace id of the first command
--recent1 <NUMBER> Open the event-log file from a recent command for the first command
--path2 <PATH2> A path to an event-log file of the second command
--trace-id2 <TRACE_ID2> Trace id of the second command
--recent2 <NUMBER> Open the event-log file from a recent command for the second command
--format <FORMAT> Which output format to use for this command
- Default value: readable
- Possible values:
  - readable: Human-readable output (default)
  - json: JSON format, one object per line

`bsmr log external-configs`¶

Display the values and origins of external configs for a selected command.

Bsmrconfigs are computed by joining together values from various inputs (repo, well-known directories, CLI flags). Each of these is logged in the given order, with later components overriding earlier ones. For config files originating from the repo (i.e. project-relative paths), except .bsmr.local, we log the path, not the actual values.

Usage: bsmr log external-configs [OPTIONS] [PATH]

Arguments:¶

<PATH> A path to an event-log file to read from

Common Options:¶

Common options are documented under Global options.

Options:¶

--recent <NUMBER> Open the event-log file from a recent command
--trace-id <ID> Show log by trace id
--no-remote Do not download the log if it is not found locally
--format <FORMAT> Which output format to use for this command
- Default value: readable
- Possible values:
  - readable: Human-readable output (default)
  - tabulated: Tab-delimited output. Deprecated in favor of readable
  - json: JSON format, one object per line
  - csv: Comma-separated values (CSV) format

`bsmr log chrome-trace`¶

Generates a Chrome trace from a bsmr event log

Usage: bsmr log chrome-trace [OPTIONS] --trace-path <TRACE_PATH> [PATH]

Arguments:¶

<PATH> A path to an event-log file to read from

Common Options:¶

Common options are documented under Global options.

Options:¶

--trace-path <TRACE_PATH> Where to write the chrome trace JSON. If a directory is passed, the filename of the event log will be used as a base filename.
--instant <TIMESTAMP DESCRIPTION> Places a global instant event at the specified time. Floating point seconds and integer nanoseconds unixtime is accepted.
--max-tracks <MAX_TRACKS> How many tracks to render events into
--recent <NUMBER> Open the event-log file from a recent command
--trace-id <ID> Show log by trace id
--no-remote Do not download the log if it is not found locally

`bsmr lsp`¶

Start an LSP server for starlark files

Usage: bsmr lsp [OPTIONS]

Common Options:¶

Common options are documented under Global options.

Options:¶

--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

Open a subscription channel to the Bessemer daemon. This allows you to interact with the Bessemer daemon via the stdin and stdout of this command: you send requests to the daemon by writing to stdin, and you get responses via stdout.

The protocol used by this command is length-prefixed protobuf. This format is a repeated series of a varint followed by a record of the length indicated by said varint.

The protobuf spec for those records is described in bsmr_subscription_proto/subscription.proto. The client writes SubscriptionRequest and reads SubscriptionResponse. See the documentation in subscription.proto to discover available APIs.

This API does not (currently) allow invalid requests and will error out when one is sent.

Usage: bsmr subscribe [OPTIONS]

Common Options:¶

Common options are documented under Global options.

Options:¶

--active-commands Whether to request command snapshots
--unstable-json Whether to get output as JSON. The JSON format is deemed unstable so this should only be used for debugging
--disable-starlark-types Disable runtime type checking in Starlark interpreter.

This option is not stable, and can be used only locally to diagnose evaluation performance problems.
--stack Record or show target call stacks.

Starlark call stacks will be included in duplicate targets error.

If a command outputs targets (like targets command), starlark call stacks will be printed after the targets.
--profile-patterns <PROFILE_PATTERNS> Enables profiling for all evaluations whose evaluation identifier matches one of the provided patterns.

Some examples identifiers: analysis/root//app/bsmr_action_impl:bsmr_action_impl (cfg:linux-x86_64#27ac5723e0c99706) load/cell//build_defs/json.bzl load/prelude//playground/test.bxl load/cell//build_defs/json.bzl@other_cell load_buildfile/upstream//third-party-bsmr/platform010/build/ncurses load_packagefile/upstream//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (root//platform/execution:linux-x86_64#08961b14cfb182aa) bxl/prelude//playground/test.bxl:playground

You can pass --profile-patterns=.* to enable no-op profiling for everything (additionally pass --profile-patterns-mode=none to use no-op profiling to just get a list of all the identifiers).

The profile results will be written to individual .profile files in <ROOT_OUTPUT>/<data+time>-<uuid>/ where ROOT_OUTPUT comes from the --profile-patterns-output flag. In that directory there will also be a file listing all the identifiers that were profiled.

Enabling/disabling profiling of an evaluation will invalidate the results of that evaluation and it will be recomputed. In some cases, this will cause other work to also need to be redone (for example, invalidating the result of loading PACKAGE files causes all consumers to be recomputed). But if you keep profiling options consistent between commands, only the work that is otherwise invalidated will be redone (and only for those would profiling results be created).

You must also pass --profile-patterns-mode and --profile-patterns-output.
--profile-patterns-output <PATH>
--profile-patterns-mode <PROFILE_PATTERNS_MODE> Profile mode.

Memory profiling modes have suffixes either -allocated or -retained.

-retained means memory kept in frozen starlark heaps after analysis completes. -retained does not work when profiling loading, because no memory is retained after loading and frozen heap is not even created. This is probably what you want when profiling analysis.

-allocated means allocated memory, including memory which is later garbage collected.
- Possible values:
  - time-flame
  - heap-allocated
  - heap-retained
  - heap-flame-allocated
  - heap-flame-retained
  - heap-summary-allocated
  - heap-summary-retained
  - statement
  - bytecode
  - bytecode-pairs
  - typecheck
  - coverage
  - none

Global options ¶

This document provides an overview of common options that are available across multiple bsmr commands.

Universal Options ¶

--isolation-dir <ISOLATION_DIR> The name of the directory that Bessemer creates within bsmr-out for writing outputs and daemon information. If one is not provided, Bessemer creates a directory with the default name.

Instances of Bessemer share a daemon if and only if their isolation directory is identical. The isolation directory also influences the output paths provided by Bessemer, and as a result using a non-default isolation dir will cause cache misses (and slower builds).
- Default value: default
- -v, --verbose <VERBOSITY> How verbose bsmr should be while logging.
Values: 0 = Quiet, errors only; 1 = Show status. Default; 2 = more info about errors; 3 = more info about everything; 4 = more info about everything + stderr;

It can be combined with specific log items (stderr, full_failed_command, commands, actions, status, stats, success) to fine-tune the verbosity of the log. Example usage "-v=1,stderr"
- Default value: 1
- --oncall <ONCALL> The oncall executing this command
--client-metadata <CLIENT_METADATA> Metadata key-value pairs to inject into Bessemer's logging. Client metadata must be of the form key=value, where key is a snake_case identifier, and will be sent to backend datasets
--agent-context <AGENT_CONTEXT> Agent context key=value pairs for telemetry. Used by AI agents to pass structured metadata. Schema is defined via bsmrconfig. Entries can be comma-separated or passed as separate flags. Examples: --agent-context intent=fix,attempt=2,prior_error=missing_target --agent-context intent=build --agent-context attempt=1

Event Log Options ¶

--event-log <PATH> Write events to this log file
--write-build-id <PATH> Write command invocation id into this file
--build-event-jsonl <PATH> Write stable, versioned build observations as JSON Lines
--unstable-write-invocation-record <PATH> Write the invocation record (as JSON) to this path. No guarantees whatsoever are made regarding the stability of the format
--command-report-path <PATH> Write the command report to this path. A command report is always written to bsmr-out/default/<uuid>/command_report even without this flag

Bsmrconfig Options ¶

-c, --config <SECTION.OPTION=VALUE> List of config options
--config-file <PATH> List of config file paths
--fake-host <HOST>
- Possible values:
  - default
  - linux
  - macos
  - windows
- --fake-arch <ARCH>
- Possible values:
  - default
  - aarch64
  - x8664
- --fake-xcode-version <VERSION-BUILD> Value must be formatted as: version-build (e.g., 14.3.0-14C18 or 14.1-14B47b)
--reuse-current-config Re-uses any --config values (inline or via modefiles) if there's a previous command, otherwise the flag is ignored.

If there is a previous command and --reuse-current-config is set, then the old config is used, ignoring any overrides.

If there is no previous command but the flag was set, then the flag is ignored, the command behaves as if the flag was not set at all.
--preemptible <PREEMPTIBLE> Used to configure when this command could be preempted by another command for the same isolation dir.

Normally, when you run two commands - from different terminals, say - bsmr will attempt to run them in parallel. However, if the two commands are based on different state, that is they either have different configs or different filesystem states, bsmr cannot run them in parallel. The default behavior in this case is to block the second command until the first completes.
- Possible values:
  - never: (default) When another command starts that cannot run in parallel with this one, block that command
  - always: When another command starts, interrupt this command, even if they could run in parallel. There is no good reason to use this other than that it provides slightly nicer superconsole output
  - ondifferentstate: When another command starts that cannot run in parallel with this one, interrupt this command
- --exit-when <EXIT_WHEN> Whether to proceed with or fail this invocation based on the daemon state
- Possible values:
  - never: (default) Execute this command normally
  - differentstate: Fail this command if another command is already running with a different state
  - notidle: Fail this command if another command is already running (regardless of daemon state)

Console Options ¶

--console <super|simple|...> Which console to use for this command
- Default value: auto
- Possible values:
  - auto
  - none
  - simple
  - simplenotty
  - simpletty
  - super
- --ui <UI> Configure additional superconsole ui components.
Accepts a comma-separated list of superconsole components to add. Possible values are:

dice - shows information about evaluated dice nodes debugevents - shows information about the flow of events from bsmrd

These components can be turned on/off interactively. Press 'h' for help when superconsole is active.
- Possible values:
  - dice
  - debugevents
  - io: I/O panel
  - re: RE panel
- --no-interactive-console Disable console interactions