6.5.4 Selecting Affected Targets Across Configurations

One affected-target set cannot safely stand for every way CI builds a repository. A dependency selected by select() may exist only on Windows, a transition may create another configured instance of a target, and toolchain resolution may add an edge for one execution platform but not another. If the selector analyzes only the default Linux build, an empty result says nothing about those unexamined graphs.

The practical rule is simple: selection coverage is a matrix, not a single graph. Define the supported top-level roots and configurations, compare the relevant graph for every supported cell, and combine only results whose identity and coverage remain explicit.

Start from the CI Work You Promise to Protect

6.5.1 Affected-Target Service Contract defined a selection universe as revisions, candidate roots, configurations, platforms, toolchains, and selector identity. Here the important part is that “configuration” is not merely a friendly name such as release. It is the effective collection of build options and platform/toolchain choices under which Bazel analyzes a top-level request.

A service contract might declare this matrix:

The selector need not support every configuration a developer could invent. It must support every cell for which its consumer treats unaffected as permission to skip work. Deciding which cells deserve that protection is an organizational policy developed in H.7.3 Evidence Selection; the selector's technical responsibility is to state and prove the cells it actually covers.

Do not infer roots from labels returned by a query. Top-level roots help construct the configured graph in the first place. Bazel's cquery documentation recommends an explicit --universe_scope for queries more complex than a simple dependency closure because transitions can configure a target differently when it appears beneath another root.¹ The same label can therefore appear as multiple configured targets, including target and execution configurations.²

Choose Target or Configured-Target Evidence Deliberately

query and cquery do not offer two interchangeable serializations of one graph:

• query examines the target graph after loading, before build options resolve configurable attributes. It conservatively includes all possible branches of a select().
• cquery examines configured targets after analysis. It resolves the branch selected by the supplied options and observes transitions and resolved toolchain dependencies for the analyzed roots.³

That creates an engineering trade-off rather than a universal winner. An unconfigured target graph can be cheaper to produce and can deliberately overapproximate configuration-dependent edges. A configured graph can represent a particular build more precisely, but only for the roots and configuration inputs that were analyzed. The published BazelDiff implementation supports both modes, and its authors report that configured-query mode has a significant performance cost.⁴

Choose the evidence according to the selector's promised result:

Using query is not automatically unsafe, and using cquery is not automatically complete. Completeness comes from matching evidence to the declared matrix and proving the relationship. A precise configured graph for the wrong root or platform is precise evidence about the wrong build.

Treat Each Matrix Cell as Comparison Evidence

Suppose //app:binary depends on a platform-selected implementation:

filegroup(
    name = "root",
    srcs = select({
        ":linux": [":posix_io"],
        ":windows": [":win32_io"],
    }),
)

A change beneath //app:win32_io may have no path to //app:root in the Linux configured graph. If CI protects both Linux and Windows, comparing only Linux snapshots creates a false negative. The selector should compare the Windows cell too and union the affected roots:

affected(Linux,   //app:root) = {}
affected(Windows, //app:root) = {//app:root}

union for the declared request   = {//app:root}

The union is safe only when all required cells completed successfully. If the Windows head snapshot is missing, incompatible, or produced for different roots, the overall result is unknown, not the Linux result. 6.5.5 Incomplete Selector Evidence develops those freshness and compatibility checks.

Keep cell identity with the evidence. At minimum record:

• immutable base and head revisions;
• top-level root set and candidate-root boundary;
• target platform and relevant build settings;
• toolchain and execution-platform dimensions represented by the mode;
• selector, snapshot schema, and graph mode versions;
• completion state and selected labels for that cell.

Do not use Bazel's short configuration hash as the service's complete durable identity. cquery prints an opaque hash derived from build option values, and bazel config can display its contents,⁵ but the selector still needs the surrounding revision, roots, tools, schema, and declared coverage that make a comparison reproducible.

Account for Transitions, Platforms, and Toolchains

A top-level configuration does not imply that every dependency uses that same configuration. Attribute and rule transitions can change options below a root. Tool dependencies commonly move to an execution configuration, and toolchain resolution can introduce configured dependencies selected for an execution platform. A cquery universe built from the real top-level roots exposes these configured instances; a separate cquery invocation whose only top-level root is a dependency label can configure that label differently.⁶

For selection, separate two responsibilities:

1. Enumerate top-level cells. These are the CI entry points and configuration inputs the service promises to protect.
2. Preserve configurations reached inside each cell. These arise through transitions and resolution while Bazel analyzes the top-level request.

Do not attempt to enumerate every internal configuration hash as an independent CI lane. Instead, construct each supported top-level request faithfully and retain the configured dependency graph it produces. If the selector enables filters, that filtering becomes part of its completeness claim and needs a test: --notool_deps can remove paths that cross from the target configuration to a non-target configuration, --noimplicit_deps can remove implicit dependencies (including resolved toolchains), and --noinclude_aspects can remove aspect-added dependencies.⁷

6.5.3 Global Target-Selection Invalidators handles a different problem: a platform declaration, toolchain registration, transition implementation, or rc input may change the graph-producing rules themselves. When such an input changes, the selector must first decide whether its snapshots remain valid or must broaden/return unknown. Only then can it compare the supported configuration cells described here.

Test the Edge That a Single Graph Would Miss

A useful fixture needs at least two supported configurations and one deliberately asymmetric edge:

1. Define one candidate root whose dependency differs by select(), platform/toolchain resolution, or a transition.
2. Place a changed target behind only the second configuration's edge.
3. Produce compatible base and head evidence for both configurations from the same declared roots.
4. Verify that the first cell omits the root and the second selects it.
5. Verify that the combined answer includes the root and explains which cell supplied the path.
6. Remove the second cell's snapshot and require unknown rather than the first cell's empty result.

The runnable configuration-selection-matrix fixture uses this exact //app:root / //app:win32_io asymmetry. Its matrix verifier runs both configured queries, records the selected Windows cell, and proves that withholding that required cell produces unknown rather than an empty Linux answer.

Also test root dependence. Analyze a tool label alone, then analyze it beneath a root that applies an execution transition. The fixture should demonstrate that label equality does not imply configured-target equality and that the selector never reuses an isolated-root comparison as proof for the transitioned instance.

This test is more valuable than asserting that two configuration runs produce different hashes. It connects the difference to the decision CI actually consumes: a root that must not be skipped.