-
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
[7.3.1] Lockfile is always considered out-of-date if --incompatible_use_plus_in_repo_names
is set
#23279
Labels
P1
I'll work on this now. (Assignee required)
team-ExternalDeps
External dependency handling, remote repositiories, WORKSPACE file.
type: bug
Milestone
Comments
github-actions
bot
added
the
team-ExternalDeps
External dependency handling, remote repositiories, WORKSPACE file.
label
Aug 12, 2024
Wyverald
added
P1
I'll work on this now. (Assignee required)
and removed
untriaged
labels
Aug 12, 2024
Wyverald
modified the milestones:
Mainline issues targeted for 7.3.0,
7.3.1 release blockers
Aug 12, 2024
Wyverald
changed the title
Lockfile is always considered out-of-date if
[7.3.1] Lockfile is always considered out-of-date if Aug 12, 2024
--incompatible_use_plus_in_repo_names
is set--incompatible_use_plus_in_repo_names
is set
This is kind of a weird one, as it doesn't exist on master, only on release-7.3.0 (well, and release-7.3.1). On master, this flag is enabled by default, and cannot actually be turned off -- so the fix will only apply to the release branch. |
Wyverald
added a commit
that referenced
this issue
Aug 12, 2024
…ble_use_plus_in_repo_names` We write a different lockfile version based on `--incompatible_use_plus_in_repo_names` (see HACK in `BazelLockFileModule.java`). But we don't _expect_ a different lockfile version based on that flag; this causes us to consider the lockfile _always_ out-of-date when that flag is set. Fixes #23279.
Wyverald
added a commit
that referenced
this issue
Aug 12, 2024
…ble_use_plus_in_repo_names` We write a different lockfile version based on `--incompatible_use_plus_in_repo_names` (see HACK in `BazelLockFileModule.java`). But we don't _expect_ a different lockfile version based on that flag; this causes us to consider the lockfile _always_ out-of-date when that flag is set. Fixes #23279.
Wyverald
added a commit
that referenced
this issue
Aug 12, 2024
…ble_use_plus_in_repo_names` We write a different lockfile version based on `--incompatible_use_plus_in_repo_names` (see HACK in `BazelLockFileModule.java`). But we don't _expect_ a different lockfile version based on that flag; this causes us to consider the lockfile _always_ out-of-date when that flag is set. Fixes #23279.
keertk
pushed a commit
that referenced
this issue
Aug 13, 2024
…ble_use_plus_in_repo_names` (#23281) We write a different lockfile version based on `--incompatible_use_plus_in_repo_names` (see HACK in `BazelLockFileModule.java`). But we don't _expect_ a different lockfile version based on that flag; this causes us to consider the lockfile _always_ out-of-date when that flag is set. Fixes #23279.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
P1
I'll work on this now. (Assignee required)
team-ExternalDeps
External dependency handling, remote repositiories, WORKSPACE file.
type: bug
Description of the bug:
If
--incompatible_use_plus_in_repo_names
is set, Bazel 7.3.0 generates a lockfile with version 12. However, this lockfile is always considered out-of-date by Bazel, since it doesn't recognize that 12 is actually the correct version when--incompatible_use_plus_in_repo_names
is set, and still expects 11 (see https://cs.opensource.google/bazel/bazel/+/release-7.3.0:src/main/java/com/google/devtools/build/lib/bazel/bzlmod/BazelLockFileFunction.java;drc=691149afd591078dc616e0143bc92bed96deedb3;l=106)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.
Which operating system are you running Bazel on?
macOS
What is the output of
bazel info release
?7.3.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
?No response
If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
No response
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: