Add regression test for #228 external go deps appear in bzlmod hashes

[tinder-maxwellelliott]

Summary

The user in #228 asked:

Trying to understand if bazel-diff still works for go deps brought in via the new gazelle/rules_go bzlmod mechanism ... Our hashes file does not include any of the external go dependencies since migrating to the new mechanism.

This is a different signal from the propagation check covered by testGoModUpdateImpactsGoTargets_regressionForIssue266 (#266). That existing test confirms a go.mod version bump changes the hash of the dependent //:lib target, but it does not assert the per-module external entry is itself in the hashes JSON. #228 is exactly that question.

I reused the existing go_mod_change workspace fixture and verified by hand against the locally built CLI:

$ java -jar bazel-bin/cli/bazel-diff_deploy.jar generate-hashes \
    -w <workspace> -b bazel /tmp/hashes.json
$ jq '.hashes | keys' /tmp/hashes.json
[
  "//:BUILD",
  "//:lib",
  "//:lib.go",
  "//:lib_test",
  "//:lib_test.go",
  "//external:com_github_pkg_errors",
  "//external:gazelle",
  "//external:rules_go"
]

The //external:<apparent_name> entries are the synthetic labels BazelClient produces by querying bazel mod show_repo --output=streamed_proto (the mechanism added for #255). They give a per-bzlmod-module hash that changes when the module's resolved version changes — exactly the surface #228 was asking about.

This regression-protection test (not @Ignore'd) locks in that behaviour. It parses the hashes JSON, asserts //:lib is present (sanity), and asserts that an entry whose label contains com_github_pkg_errors exists and equals //external:com_github_pkg_errors.

Skipped on Bazel < 8.6.0 and on 9.0.0 (which had a broken mod show_repo path), matching the existing convention.

Test plan

• bazel test //cli:E2ETest --test_filter=testExternalGoDepsAppearInHashes_regressionForIssue228 passes on Bazel 9.1
• CI green

Refs #228

🤖 Generated with Claude Code