# Debugging bazel actions

DevFeed: [Debugging bazel actions](<https://devfeed.tech/articles/debugging-bazel-actions-25408.md>)

Original publisher: [Read original article](<https://smileykeith.com/2022/03/02/debugging-bazel-actions/>)

Author: Keith Smiley

Published: 2022-03-03T02:00:00Z

Content type: tutorial

Language: en

Sources: [Keith Smiley](<https://devfeed.tech/sources/keith-smiley.md>)

Topics: [debugging](<https://devfeed.tech/topics/debugging.md>), [Command-line interface](<https://devfeed.tech/topics/cli.md>), [configuration](<https://devfeed.tech/topics/configuration.md>), [Tooling](<https://devfeed.tech/topics/tooling.md>)

Tags: [bazel](<https://devfeed.tech/tags/bazel.md>), [build](<https://devfeed.tech/tags/build.md>), [command-line](<https://devfeed.tech/tags/command-line.md>), [configuration](<https://devfeed.tech/tags/configuration.md>), [debugging](<https://devfeed.tech/tags/debugging.md>), [sandbox](<https://devfeed.tech/tags/sandbox.md>)

## AI overview

This tutorial explains how to reproduce Bazel actions outside Bazel's infrastructure for debugging and benchmarking. It covers preparing the build environment, disabling or preserving sandboxing, obtaining an action's command line, and forcing actions to rerun by invalidating inputs or changing flags.

## Source excerpt

When working on bazel build infrastructure, something I often need to do is reproduce an action outside of bazel's infrastructure in order to debug it further. This debugging often involves changing flags or swapping out the tool itself for a custom built version. In many cases updating your bazel configuration as normal should work well enough. But sometimes when you're iterating on things that invalidate a significant portion of your build it can be faster to work on things outside of bazel first, and then update your bazel configuration based on your discoveries. Another case where this is useful is if you want to benchmark a specific action by running it many times individually without the contention caused by bazel parallelizing other actions. Since bazel has a lot of infrastructure for keeping builds hermetic, there are a few steps you need to take to roughly reproduce what bazel is doing so your debugging is as close to what it runs as possible. 1. Build and disable sandboxing In order for bazel to setup your build environment (including your downloaded dependencies), and leave it intact for you to muck around with, you must run a normal build and also either disable sandboxing by passing --spawn_strategy=standalone, or make it leave the sandbox base around by passing --sandbox_debug. 2. Grab your action's command line Once bazel has run and left its environment intact, you need to grab the command line being run for the action you want to debug. I find that passing bazel's -s flag (also known as --subcommands) is the easiest way to do this. You just have to make sure that the action you're interested in actually runs. There are a few different ways you can force bazel to run an action: Invalidate the inputs for the action. Unlike other build systems touching input files isn't enough, I often add newlines or comments to files to force actions to re-run. Change the flags for a command line. For some actions such as C++ compiles, or native binary linking, there