bazel run Command Reference
Build a runnable target and execute it in one command.
bazel run builds an executable target and then runs it. CI uses it for deploy rules, code generators, and tools defined inside the repo.
What it does
bazel run builds a runnable target (binary, deploy rule, or tool) and executes it in a runfiles environment. Arguments after a -- separator are passed to the program, not to Bazel.
Common flags and usage
- //path:target: the runnable target to build and execute
- -- <args>: arguments forwarded to the program
- --config=NAME: apply a named config from .bazelrc
- --run_under=CMD: wrap execution (for example a debugger)
Example
shell
- name: Run deploy target
run: bazel run --config=ci //deploy:push -- --env=stagingIn CI
Use bazel run for in-repo tools and deploy rules so the same hermetic build feeds the action. Always place program arguments after -- so Bazel does not interpret them as its own flags.
Using this in CI
- Set the shell explicitly and enable
set -euo pipefail; the default runner shell does not stop on the first error inside a multi-line block. - Pin the tool version. An unpinned build tool turns a runner image update into a build break on unchanged code.
- Prefer non-interactive and batch flags. Progress output designed for a terminal bloats CI logs and can hang without a TTY.
- Write machine-readable output (JSON, JUnit) to a file and upload it as an artifact, so a failure is diagnosable without re-running the job.
Key takeaways
- bazel run builds then executes a runnable target.
- Arguments after -- go to the program, not to Bazel.
- Ideal for in-repo deploy rules, codegen, and tools.
Frequently asked questions
bazel run Command Reference?
bazel run builds an executable target and then runs it. CI uses it for deploy rules, code generators, and tools defined inside the repo.
What it does?
bazel run builds a runnable target (binary, deploy rule, or tool) and executes it in a runfiles environment. Arguments after a -- separator are passed to the program, not to Bazel.
In CI?
Use bazel run for in-repo tools and deploy rules so the same hermetic build feeds the action. Always place program arguments after -- so Bazel does not interpret them as its own flags.
Related guides
actionlint: Lint GitHub Actions Workflowsactionlint statically checks .github/workflows YAML for syntax, expression, and shell errors.
datadog-ci sourcemaps upload for RUM Stack Tracesdatadog-ci sourcemaps upload sends JS source maps to Datadog so RUM error stack traces deminify.
dotnet ef migrations: EF Core Migrations in CIdotnet ef migrations and database update apply EF Core schema changes.