Bazel Targets

Bazel Targets

This document lists the primary Bazel build targets available in the project. Targets are listed from the perspective of the overlay repository, which merges upstream and private files through the @attic_merged repository rule (see Overlay System).

Top-Level Targets

These targets are defined in the overlay repository root BUILD.bazel and represent the most common build operations.

Target Description
//... Build all targets in the workspace. This includes both overlay-defined targets and upstream targets pulled in through @attic_merged. Bazel’s content-addressable cache ensures unchanged targets resolve instantly.
//:deployment_bundle A pkg_tar archive containing declared Kubernetes YAML manifests and Nix files. Used for deployment artifact packaging.
//:validate_modules Alias to @attic-iac//tofu/modules:all_validate. Runs tofu validate against all upstream OpenTofu modules.
//:app Alias to @attic-iac//app:build. Produces the Vite production build of the runner dashboard SvelteKit application.
//:docs_content Filegroup containing declared Markdown documentation consumed by the docs-site Bazel package.

Application Targets

These targets are defined in //app/ and operate on the SvelteKit runner dashboard.

Target Description
//app:build Vite production build. Compiles the SvelteKit application with adapter-node, producing a Node.js server bundle in build/.
//app:dev Vite development server. Starts the SvelteKit dev server with hot module replacement. This is a run target, not a build target; invoke it through the cache-backed wrapper.
//app:image OCI image manifest. Assembles a container image from the production build output using image_layer and image_manifest rules.
//app:push Push the OCI image to ghcr.io. Requires registry authentication to be configured. Invoke it through the cache-backed wrapper.

Docs-Site Targets

These targets are defined in //docs-site/ and operate on the static documentation site.

Target Description
//docs-site:build Vite adapter-static docs-site build over declared docs-site sources, static assets, package config, and docs files.
//docs-site:dev Vite development server for the docs site. This is an interactive run target and is not RBE-eligible.

Target Dependency Graph

Running Targets

Treat the shared cache-backed Bazel path as the normal contract:

  • enter the repo via direnv allow or nix develop
  • confirm BAZEL_REMOTE_CACHE is set if you are not already on a self-hosted runner that injects it
  • use the repo-managed cache-backed wrapper for heavy Bazel work

Raw local Bazel execution without that configuration is a compatibility/debug path only.

Build targets are normally invoked through the cache-backed wrapper:

# Build everything against the shared cache-backed substrate
scripts/bazel-cache-backed.sh build //...

# Build only the deployment bundle
scripts/bazel-cache-backed.sh build //:deployment_bundle

# Validate all OpenTofu modules
scripts/bazel-cache-backed.sh build //:validate_modules

# Build the SvelteKit app
scripts/bazel-cache-backed.sh build //:app

# Build the static docs site
scripts/bazel-cache-backed.sh build //docs-site:build

Run targets (dev server, image push) are invoked through the same wrapper:

# Start the dev server
scripts/bazel-cache-backed.sh run //app:dev

# Push the container image
scripts/bazel-cache-backed.sh run //app:push

Speculative Builds

Running scripts/bazel-cache-backed.sh build //... is the recommended default once the shared cache-backed substrate is available. Bazel’s content-addressable cache means targets whose inputs have not changed resolve as cache hits with negligible cost. Building everything ensures that:

  • Breakages in unrelated targets surface early.
  • The deployment bundle always reflects the current state of all components.
  • CI pipelines do not need to determine which subset of targets to build based on changed files.

This pairs with the Greedy Build Pattern, where the same cache-backed wrapper path runs immediately in CI without waiting for validation.

If BAZEL_REMOTE_CACHE is unset on a dev machine, Bazel falls back to a compatibility local mode. That is acceptable for bounded debugging, but it is not the intended heavy-work story for the platform.

GloriousFlywheel