-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Labels
team-ExternalDeps
External dependency handling, remote repositiories, WORKSPACE file.
type: bug
untriaged
Comments
github-actions
bot
added
the
team-ExternalDeps
External dependency handling, remote repositiories, WORKSPACE file.
label
Jan 24, 2025
This is a tricky one: We need to include the repo mapping entries we applied to each extension's @meteorcloudy @Wyverald Should this block 7.5.0 as well? |
@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
Description of the bug:
When a new
use_repo_rule
statement is added toMODULE.bazel
, the canonical names of repositories created with other repo rules may change. For example, if I have 4 pre-existinguse_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 theMODULE.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 toRepository '@@+_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.
This will produce an error: the change being fetched here adds a
use_repo_rule
statement, but theMODULE.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
returnsdevelopment 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
The text was updated successfully, but these errors were encountered: