Skip to content

Reproducer test for #197 wrapped external repo file change not detected#343

Open
tinder-maxwellelliott wants to merge 1 commit into
masterfrom
claude/reproducer-issue-197
Open

Reproducer test for #197 wrapped external repo file change not detected#343
tinder-maxwellelliott wants to merge 1 commit into
masterfrom
claude/reproducer-issue-197

Conversation

@tinder-maxwellelliott
Copy link
Copy Markdown
Collaborator

Summary

  • Adds an @Ignored E2E reproducer test for #197, specifically the unfixed shape @Ahajha called out in his comment: a target inside one external repo is re-wrapped by ANOTHER external repo, and the main repo consumes only the wrapping repo.
  • New workspace cli/src/test/resources/workspaces/wrapped_external_repo/ wires this up with bzlmod local_path_override:
    • inner_repo — filegroup wrapping data.txt
    • middle_repo — alias re-exporting @inner_repo//:all_files
    • //:consumer — genrule consuming @middle_repo//:wrapped
  • Confirmed the bug by hand against the built CLI:
    • --fineGrainedHashExternalRepos=@inner_repo → impacted is {@inner_repo//:all_files, @inner_repo//:data.txt}; //:consumer is not impacted.
    • --fineGrainedHashExternalRepos=@inner_repo,@middle_repo → impacted includes //:consumer, proving the chain works once every wrapper is enumerated.
  • Desired behaviour: listing only the source-of-truth repo (@inner_repo) is enough — bazel-diff should follow the dep chain through alias/wrapper external repos without manual enumeration. The asserted target is //:consumer.

The simple "main target → one external repo's source file" case already works on current bazel-diff (probably fixed since the issue was filed). This PR captures the remaining, more subtle shape.

This is a test-only change. The reproducer is @org.junit.Ignored so CI stays green; the annotation documents the issue it tracks. The workspace fixture follows the same pattern as the existing distance_metrics, cquery_failing_target, and macro_invalidation workspaces.

Test plan

  • bazel build //cli:cli-test-lib succeeds.
  • bazel query 'deps(//:consumer)' from the new workspace returns @inner_repo//:data.txt (the chain is intact).
  • bazel test //cli:E2ETest is unchanged (the new test is @Ignored and skipped).
  • Manual run with the locally built CLI against a copy of the workspace, mutating inner_repo/data.txt, confirms the bug (see Summary above).
  • After propagation through wrapped repos is fixed, remove @Ignore and re-run the test — it should pass without the user enumerating every wrapping repo.

🤖 Generated with Claude Code

…tected

The simple case (a main-repo target consuming a file from a single
external repo) works on current bazel-diff. The unfixed shape is the one
@Ahajha called out: a target inside one external repo is re-wrapped by
ANOTHER external repo, and the main repo consumes only the wrapping
repo. When the inner repo's source file changes, the main-repo consumer
should be reported as impacted -- today it is not, unless the user
manually enumerates every wrapping external repo in
--fineGrainedHashExternalRepos.

The new `wrapped_external_repo` fixture wires this up with bzlmod:
  inner_repo  -> filegroup wrapping data.txt
  middle_repo -> alias re-exporting @inner_repo//:all_files
  //:consumer -> genrule consuming @middle_repo//:wrapped

Confirmed by hand against the built CLI:
  --fineGrainedHashExternalRepos=@inner_repo
    -> impacted: @inner_repo//:all_files, @inner_repo//:data.txt
    -> //:consumer NOT impacted (bug)
  --fineGrainedHashExternalRepos=@inner_repo,@middle_repo
    -> impacted includes //:consumer (workaround proves the chain works
       when every wrapper is enumerated)

The reproducer test asserts that listing only the source-of-truth repo
is enough. It is @ignore'd until propagation through alias/wrapper
external repos works.

Refs #197

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@tinder-maxwellelliott tinder-maxwellelliott force-pushed the claude/reproducer-issue-197 branch from 311be6f to 6b91f03 Compare May 13, 2026 19:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant