Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lockfile fails to be regenerated when use_repo_rule statements are added #25063

Open
tpudlik opened this issue Jan 24, 2025 · 2 comments · May be fixed by #25067
Open

Lockfile fails to be regenerated when use_repo_rule statements are added #25063

tpudlik opened this issue Jan 24, 2025 · 2 comments · May be fixed by #25067
Assignees
Labels
team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: bug untriaged

Comments

@tpudlik
Copy link
Contributor

tpudlik commented Jan 24, 2025

Description of the bug:

When a new use_repo_rule statement is added to MODULE.bazel, the canonical names of repositories created with other repo rules may change. For example, if I have 4 pre-existing use_repo_rule statements and inset a new one between the 3rd and 4th, repositories created with the last repo rule will now be prefixes with @+_repo_rules5+ where before they were prefixed with @+_repo_rules4+. This naming change requires updating any references to these repositories in the MODULE.bazel.lock file.

However, these references are not always updated. For example, references in the attributes of other repository rules may not be updated, even after running bazel mod deps --lockfile_mode=update, leading to Repository '@@+_repo_rules4+[name]' is not defined errors at build time. See https://pwbug.dev/392155942 for a concrete real-world example of this.

Which category does this issue belong to?

External Dependency

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

git clone https://pigweed.googlesource.com/pigweed/pigweed
cd pigweed
git fetch https://pigweed.googlesource.com/pigweed/pigweed refs/changes/51/211451/7 && git checkout -b change-211451 FETCH_HEAD
bazelisk query 'attr("includes", "[.{1,}]", kind(cc_library, //...))'

This will produce an error: the change being fetched here adds a use_repo_rule statement, but the MODULE.bazel.lock file is outdated.

You can then fix this error by updating the MODULE.bazel.lock file manually: on lines 1111 thru 1114, replace the @@+_repo_rules4 prefix with @@+_repo_rules5, and the query will succeed.

@Wyverald

Which operating system are you running Bazel on?

Linux

What is the output of bazel info release?

release 8.0.0

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?


If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

I don't believe this is a regression.

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

@github-actions github-actions bot added the team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. label Jan 24, 2025
@fmeum
Copy link
Collaborator

fmeum commented Jan 25, 2025

This is a tricky one: We need to include the repo mapping entries we applied to each extension's attr.label tag attributes into the extension's usages hash.

@meteorcloudy @Wyverald Should this block 7.5.0 as well?

@fmeum
Copy link
Collaborator

fmeum commented Jan 25, 2025

@bazel-io fork 8.1.0

fmeum added a commit to fmeum/bazel that referenced this issue Jan 25, 2025
The mapping of an apparent name in a module extension tag's `attr.label`
attribute to the corresponding canonical name has to be recorded in the
lockfile so that instantiated repo rules don't reference the stale
repos.

Fixes bazelbuild#25063
fmeum added a commit to fmeum/bazel that referenced this issue Jan 25, 2025
The mapping of an apparent name in a module extension tag's `attr.label`
attribute to the corresponding canonical name has to be recorded in the
lockfile so that instantiated repo rules don't reference the stale
repos.

Fixes bazelbuild#25063
fmeum added a commit to fmeum/bazel that referenced this issue Jan 25, 2025
The mapping of an apparent name in a module extension tag's `attr.label`
attribute to the corresponding canonical name has to be recorded in the
lockfile so that instantiated repo rules don't reference the stale
repos.

Fixes bazelbuild#25063
fmeum added a commit to fmeum/bazel that referenced this issue Jan 25, 2025
The mapping of an apparent name in a module extension tag's `attr.label`
attribute to the corresponding canonical name has to be recorded in the
lockfile so that instantiated repo rules don't reference the stale
repos.

Fixes bazelbuild#25063
fmeum added a commit to fmeum/bazel that referenced this issue Jan 25, 2025
The mapping of an apparent name in a module extension tag's `attr.label`
attribute to the corresponding canonical name has to be recorded in the
lockfile so that instantiated repo rules don't reference the stale
repos.

Fixes bazelbuild#25063
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: bug untriaged
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants