feat: add --alwaysAffectedTags to always impact non-hermetic tagged targets (#401)

[tinder-maxwellelliott]

Problem

Closes #401.

bazel-diff hashes a target from its declared rule inputs (plus transitive deps in the query graph). A target that reads the workspace at execution time without declaring those files as inputs — a repo-scanning linter such as buildifier_test, gofmt_test, or eslint_test — keeps a stable hash across commits that only change those undeclared files. Under target determination, the target is then wrongly skipped even though it would fail if run.

Monorepos commonly tag these non-hermetic targets with a Bazel target tag (the issue uses external). There was no first-class way to say "always treat targets with this tag as impacted" — the existing knobs don't fit (--seed-filepaths over-invalidates the whole graph; --excludeExternalTargets / --fineGrainedHashExternalRepos are about external repos, not the tag; --cqueryExpression only sees declared deps).

Change

New generate-hashes flag: --alwaysAffectedTags (comma-separated, e.g. --alwaysAffectedTags=external).

Any rule whose tags attribute contains a listed value gets a per-invocation random sentinel mixed into its hash, so a diff of the base and head hash files always reports it as impacted. The tag name is the caller's convention — nothing is hardcoded.

bazel-diff generate-hashes --alwaysAffectedTags=external -w "$WORKSPACE" -b "$BAZEL" hashes.json

How it works

• BazelRule.tags() reads the tags STRING_LIST attribute from the query/cquery proto.
• RuleHasher mixes the sentinel into the tagged rule's direct digest, so it is classified DIRECT-impacted for build-graph distance metrics. It also bubbles into the overall digest, so any rdeps are conservatively re-hashed too.
• The sentinel is minted once per invocation in hasherModule, and only when the flag is set. When the feature is unused nothing is mixed, so every hash is byte-for-byte identical to before and untagged targets never over-invalidate.

Design notes for reviewers

• Sentinel = per-invocation nonce, not HEAD commit SHA. The issue floated both. The nonce was chosen because core generate-hashes has no git dependency, and it guarantees "always affected" even for non-git workspaces, shallow clones, dirty trees, and same-commit re-runs (a commit SHA would not mark the target affected when base == head). Trade-off: tagged targets' hashes are intentionally non-deterministic across runs; everything untagged stays deterministic.
• Cascade is intentional. Mixing into the digest necessarily flows into the overall digest that dependents consume, so rdeps of a tagged target are re-hashed. For the leaf test targets in the motivating issue there are no rdeps; for the general case it's a safe over-approximation. Documented in code + README.
• Scope is limited to generate-hashes; serve / get-impacted-targets pass the (defaulted-empty) parameter unchanged.

Tests

• New RuleHasherAlwaysAffectedTagsTest: tagged target changes across invocations (overall + direct digest), untagged/unlisted-tag targets stay stable, enabling the flag doesn't perturb untagged targets, and it's inert when no tags are configured.
• BazelRuleTest: tags() extraction (present / absent).
• BazelDiffTest: CLI parsing of --alwaysAffectedTags (and empty default).

bazel test //cli:all → 34/35 pass locally. The lone failure is //cli:E2ETest, which is environmental in this sandbox (nested Bazel: Cannot find Java binary bin/java, simulated network error resolving repository rule); it needs a full toolchain + network and never sets the new flag, so this change cannot affect it.

Docs

• README: new "Always-affected targets (non-hermetic tags)" section with a usage example, plus the regenerated generate-hashes --help block.

🤖 Generated with Claude Code