# hushrun and Bazel

Bazel is a build system that reuses builds and test results from every target's declared inputs, across a large codebase in many languages. hushrun wraps the commands you already have, and skips one when the repository's files already passed. Bazel is far more precise, and takes far more to adopt.

| | Bazel | hushrun |
|---|---|---|
| Setup | `BUILD` files for each package, with rules for each language | One `hushrun run` per command |
| Key | Every action's declared inputs | The repository's files or a scope's, the check's name, the exact command and the directory |
| A one-file change | Reruns what depends on that file | Runs every check, unless you set scopes |
| On a hit | Reuses outputs from the cache | Skips the command and restores nothing |
| Promotion to production | No | Yes |

## How Bazel reuses results

[Bazel's remote cache](https://bazel.build/remote/caching) is an action cache and a content-addressable store, over HTTP or gRPC. Sharing works when an action's outputs depend only on its declared inputs. With [`--cache_test_results=auto`](https://bazel.build/docs/user-manual), a test reruns when it or a dependency changes, when it's marked `external`, with `--runs_per_test`, or after a failure.

Precision comes from describing the project. [A package is a directory with a `BUILD` file](https://bazel.build/concepts/build-ref), and each target lists its inputs. [Hermetic builds](https://bazel.build/basics/hermeticity) are what make the results trustworthy.

## How hushrun differs

- **Adoption takes minutes.** One wrapper, not a migration. Bazel is a project of its own for most teams.
- **Precision is coarser.** hushrun has no dependency graph: it knows the files, and the [scopes](https://hushrun.com/docs/run.md#monorepos) you draw. In a repository where most changes touch a few of thousands of targets, Bazel wins.
- **It trusts you on what's outside the files.** Bazel can isolate a test from undeclared inputs. hushrun can't: a check that reads an environment variable needs [a name per variant](https://hushrun.com/docs/run.md#same-code).
- **It goes on to deploy.** [Promotion](https://hushrun.com/docs/promotion.md) deploys the artifact staging validated, by digest, with signed evidence.

## Using both

Bazel already skips work inside a run, so wrapping it saves the rest: analysis, and fetching from the cache, on code that already passed.

```json title="package.json"
"scripts": {
  "test": "hushrun run -- bazel test //..."
}
```

## Which to choose

- **Choose Bazel** for a large, multi-language codebase with a team that can own the build.
- **Choose hushrun** when you want repeated checks gone without changing how the repository builds.
- **If you're looking for a Bazel alternative** because the migration is too much: hushrun gets you the reuse of passing checks, not faster builds. [Bazel's FAQ](https://bazel.build/about/faq) compares it with Make, Ninja, Maven, Gradle, Pants and Buck, and [Nx](https://hushrun.com/docs/compare/nx-cloud.md) or [Turborepo](https://hushrun.com/docs/compare/turborepo.md) suit JavaScript monorepos.

## Related

- [Cache test results across machines](https://hushrun.com/docs/guides/cache-test-results.md)
- [hushrun and the alternatives](https://hushrun.com/docs/compare.md)