-
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
Using invalid patch path with bzlmod + lockfile results in crash and bad lockfile #21845
Labels
area-Bzlmod
Bzlmod-specific PRs, issues, and feature requests
P1
I'll work on this now. (Assignee required)
team-ExternalDeps
External dependency handling, remote repositiories, WORKSPACE file.
type: bug
Comments
sgowroji
added
team-ExternalDeps
External dependency handling, remote repositiories, WORKSPACE file.
area-Bzlmod
Bzlmod-specific PRs, issues, and feature requests
labels
Mar 28, 2024
meteorcloudy
added
P1
I'll work on this now. (Assignee required)
and removed
untriaged
labels
Apr 16, 2024
Wyverald
added a commit
that referenced
this issue
Apr 18, 2024
Today, a repo rule's attributes might contain invalid labels because of unresolved apparent repo names. This could be due to either module extensions generating bad repo definitions, or users providing e.g. bad labels to `patches` attribute of overrides. This causes us to write a label like `@@[unknown repo 'foo' requested from @@]//:bar` into the lockfile, which will cause Bazel to crash on a subsequent attempt to parse the lockfile. This PR fixes it so that we throw an error at the time of writing the lockfile, instead of writing a corrupted lockfile that users can't recover from unless they manually delete it. In the unlikely event that we do have a corrupted lockfile, we also no longer crash, but give a helpful error message instead. Fixes #21845.
Wyverald
added a commit
that referenced
this issue
Apr 18, 2024
Today, a repo rule's attributes might contain invalid labels because of unresolved apparent repo names. This could be due to either module extensions generating bad repo definitions, or users providing e.g. bad labels to `patches` attribute of overrides. This causes us to write a label like `@@[unknown repo 'foo' requested from @@]//:bar` into the lockfile, which will cause Bazel to crash on a subsequent attempt to parse the lockfile. This PR fixes it so that we throw an error at the time of writing the lockfile, instead of writing a corrupted lockfile that users can't recover from unless they manually delete it. In the unlikely event that we do have a corrupted lockfile, we also no longer crash, but give a helpful error message instead. Fixes #21845.
Wyverald
added a commit
that referenced
this issue
Apr 18, 2024
Today, a repo rule's attributes might contain invalid labels because of unresolved apparent repo names. This could be due to either module extensions generating bad repo definitions, or users providing e.g. bad labels to `patches` attribute of overrides. This causes us to write a label like `@@[unknown repo 'foo' requested from @@]//:bar` into the lockfile, which will cause Bazel to crash on a subsequent attempt to parse the lockfile. This PR fixes it so that we throw an error at the time of writing the lockfile, instead of writing a corrupted lockfile that users can't recover from unless they manually delete it. In the unlikely event that we do have a corrupted lockfile, we also no longer crash, but give a helpful error message instead. Fixes #21845.
Wyverald
added a commit
that referenced
this issue
Apr 18, 2024
Today, a repo rule's attributes might contain invalid labels because of unresolved apparent repo names. This could be due to either module extensions generating bad repo definitions, or users providing e.g. bad labels to `patches` attribute of overrides. This causes us to write a label like `@@[unknown repo 'foo' requested from @@]//:bar` into the lockfile, which will cause Bazel to crash on a subsequent attempt to parse the lockfile. This PR fixes it so that we throw an error at the time of writing the lockfile, instead of writing a corrupted lockfile that users can't recover from unless they manually delete it. In the unlikely event that we do have a corrupted lockfile, we also no longer crash, but give a helpful error message instead. Fixes #21845.
Wyverald
added a commit
that referenced
this issue
Apr 18, 2024
Today, a repo rule's attributes might contain invalid labels because of unresolved apparent repo names. This could be due to either module extensions generating bad repo definitions, or users providing e.g. bad labels to `patches` attribute of overrides. This causes us to write a label like `@@[unknown repo 'foo' requested from @@]//:bar` into the lockfile, which will cause Bazel to crash on a subsequent attempt to parse the lockfile. This PR fixes it so that we throw an error at the time of writing the lockfile, instead of writing a corrupted lockfile that users can't recover from unless they manually delete it. In the unlikely event that we do have a corrupted lockfile, we also no longer crash, but give a helpful error message instead. Fixes #21845.
This was referenced May 22, 2024
copybara-service bot
pushed a commit
that referenced
this issue
May 22, 2024
The following validation checks were not enforced due to backwards compatibility concerns, but ended up crashing Bazel when invalid labels made it into the lockfile, which is enabled by default. We might as well enable them now: * Fail if a label passed to `use_extension` is not valid * Fail if a label passed to the `patches` attribute of an override is not valid or points to a repo other than the main repo Work towards #21845 Closes #22487. PiperOrigin-RevId: 636255834 Change-Id: I55dda374cd1716e514c4d78642479b136fd3ad43
iancha1992
pushed a commit
to iancha1992/bazel
that referenced
this issue
May 22, 2024
The following validation checks were not enforced due to backwards compatibility concerns, but ended up crashing Bazel when invalid labels made it into the lockfile, which is enabled by default. We might as well enable them now: * Fail if a label passed to `use_extension` is not valid * Fail if a label passed to the `patches` attribute of an override is not valid or points to a repo other than the main repo Work towards bazelbuild#21845 Closes bazelbuild#22487. PiperOrigin-RevId: 636255834 Change-Id: I55dda374cd1716e514c4d78642479b136fd3ad43
github-merge-queue bot
pushed a commit
that referenced
this issue
May 22, 2024
The following validation checks were not enforced due to backwards compatibility concerns, but ended up crashing Bazel when invalid labels made it into the lockfile, which is enabled by default. We might as well enable them now: * Fail if a label passed to `use_extension` is not valid * Fail if a label passed to the `patches` attribute of an override is not valid or points to a repo other than the main repo Work towards #21845 Closes #22487. PiperOrigin-RevId: 636255834 Change-Id: I55dda374cd1716e514c4d78642479b136fd3ad43 Commit cdace8f Co-authored-by: Fabian Meumertzheim <[email protected]>
bazel-io
pushed a commit
to bazel-io/bazel
that referenced
this issue
May 24, 2024
Catches a common gotcha of referencing a repo created by an extension elsewhere in an extension without a `use_repo` and provides actionable advice to user. This prevents lockfile corruption caused by non-visible labels. The same validation is applied to labels in tag attributes. Fixes bazelbuild#21845 Closes bazelbuild#22495. PiperOrigin-RevId: 636939357 Change-Id: Ib779207502f7767e4e8d3abc55ba7470f75821b9
github-merge-queue bot
pushed a commit
that referenced
this issue
May 24, 2024
…xtensions (#22537) Catches a common gotcha of referencing a repo created by an extension elsewhere in an extension without a `use_repo` and provides actionable advice to user. This prevents lockfile corruption caused by non-visible labels. The same validation is applied to labels in tag attributes. Fixes #21845 Closes #22495. PiperOrigin-RevId: 636939357 Change-Id: Ib779207502f7767e4e8d3abc55ba7470f75821b9 Commit aa436c3 Co-authored-by: Fabian Meumertzheim <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area-Bzlmod
Bzlmod-specific PRs, issues, and feature requests
P1
I'll work on this now. (Assignee required)
team-ExternalDeps
External dependency handling, remote repositiories, WORKSPACE file.
type: bug
Description of the bug:
It's invalid to specify a patch in your MODULE.bazel that is from a repo that's also being loaded in the MODULE.bazel. If you do this you end up corrupting your lockfile and it results in bazel crashes until you delete the lockfile.
It looks like the issue is the invalid patch path gets encoded in the lockfile before it's rejected:
Then bazel crashes with:
Which category does this issue belong to?
No response
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
It has to be patching a module that is used during the build
USE_BAZEL_VERSION=last_green bazelisk build //java/com/google/copybara:copybara_deploy.jar
Which operating system are you running Bazel on?
macOS
What is the output of
bazel info release
?e03de75
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
Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.
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: