run

This document provides an overview of the commands and options available under buck2 run.

buck2 run

Build and run the selected target.

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

Usage: buck2 run [OPTIONS] <TARGET> [TARGET_ARGS]...

Arguments:

• <TARGET> Target to build and run

• <TARGET_ARGS> Additional arguments passed to the target when running it

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: $(buck2 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 Buck1 would.

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

• --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)

• --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 Buck 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 buck is to do enough work to get a result for the builds of each of :foo and :bar, and no more. This means that buck 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 buck 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 buck 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 Buck 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, buck2 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.

• -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 - buck2 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, buck2 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)

• --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/cell//buck2/app/buck2_action_impl:buck2_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/fbcode//third-party-buck/platform010/build/ncurses load_packagefile/fbcode//cli/rust/cli_delegate anon_analysis/anon//:_anon_link_rule (anon: 766183dc9b6f680a) (fbcode//buck2/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

• --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 buckd

  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

• --event-log <PATH> Write events to this log file

• --write-build-id <PATH> Write command invocation id into this file

• --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 buck-out/v2/<uuid>/command_report even without this flag