[Spikhalskiy]

Problem

When a module comes from a local registry inside the workspace (--registry=file://%workspace%/registry), Bazel expands %workspace%. The module's remote_patches, remote_file_urls and remote_module_file_urls then hold absolute file:// URLs that point into the checkout. bazel-diff hashed these attributes verbatim, so the same commit got different hashes at two paths, and diffing those hashes reported every target that depends on the module as impacted. serve instances at different paths that share a remote cache read each other's hashes and report the same false impacts, because the cache key does not include the path.

Fix

bazel-diff already leaves url/urls out of a repository's hash when sha256 or integrity pins the download. The registry URLs are pinned the same way, each by its own integrity:

• a remote_patches URL by its value,
• a remote_file_urls entry by the matching remote_file_integrity entry,
• remote_module_file_urls by remote_module_file_integrity.

The new without_integrity_pinned_urls drops each URL whose integrity is set and keeps the integrity. Patch order is still hashed, and so is any URL without an integrity. The fix doesn't need to know the workspace path, and a registry that moves to a new URL no longer changes the hash either.

It applies in two places: the //external:* target hashes, and repository_definition_hash, the hash of a module's definition that bazel-diff adds to each of the module's extension repositories.

Tests

• hash::tests::external_rule_digest_ignores_registry_urls_pinned_by_their_integrity: the same rule under two checkout roots hashes the same. A changed or reordered patch, a changed overlay file or MODULE.bazel, or an unpinned patch, overlay or MODULE.bazel URL still changes the hash.
• bazel::tests::extension_repos_carry_their_owning_modules_definition: repository_definition_hash ignores the checkout path in a remote_patches URL and still changes when the patch integrity changes.
• New e2e case regressions::registry_urls_under_the_workspace_do_not_depend_on_its_path: it adds a registry patch to the single_version_override_patch fixture. Two identical copies at different paths now impact nothing (before the fix: //:consumer), and a changed registry patch still impacts //:consumer. I regenerated tools/e2e/rust_e2e_cases.bzl.
• All three fail without the fix. With the fixed binary, the reproduction script from Repository hashes depend on the checkout path when a module comes from a file://%workspace% registry #544 prints no impacted targets.
• I ran cargo test --lib, cargo clippy --all-targets -- -D warnings, cargo fmt --check, the regen check, and the Bzlmod, extension-repo and single-version-override e2e cases on Bazel 8.7.0; they pass. external::bzlmod_transitive_deps_cquery fails on my machine because it has no JDK; this is unrelated to the change.

Fixes #544.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.