Fix lockfile refs for binary-less and cached artifacts#1588
Open
shs96c wants to merge 3 commits into
Open
Conversation
A binary-less aggregator coordinate -- one with no artifact of its own,
such as a Gradle module-metadata umbrella, an `available-at` redirect, or
a `<packaging>pom</packaging>` POM -- can share its `group:artifact` key
with a classified sibling that owns the only shasum. When it does, the
lock file records that key with shasums like `{"unshaded": ...}` and no
`jar` entry, so neither AbstractMain.calculateArtifactHash nor its
Starlark mirror in v3_lock_file.bzl reconstructs the plain
`group:artifact` key. The plain key still appears in the `repositories`
and `dependencies` sections, so walking those sections threw a
NullPointerException (Java) and failed with "key not found in dictionary"
(Starlark) when resolving real repositories.
- Skip artifacts with no reconstructed entry when assigning repositories
and dependencies during hashing; they contribute no hashable artifact.
The Java and Starlark computations are kept in lock-step so the stored
__RESOLVED_ARTIFACTS_HASH still matches.
- Filter dependency edges that point at a coordinate with no generated
target (_artifact_keys + _filter_dependency_targets) so the BUILD-file
generator never emits a dangling target reference.
Adds a Java regression test reproducing the exact lock-file shape and
Starlark unit tests for both guards (and registers the previously unwired
tests/unit/v3_lock_file_test.bzl suite).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
shs96c
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Some Gradle Module Metadata resolutions can produce coordinates that are useful for dependency graph shape but do not correspond to an emitted jar target. This exposed two ways a freshly repinned lockfile could be generated successfully but fail when Bazel later tried to use it:
repositoriesor dependency edges even though the artifact key was not emitted inartifacts.This changes lockfile generation to keep the emitted artifact set and all repository/dependency references consistent.
It also tightens the Gradle resolver and downloader path handoff so a local file is only used as the known artifact path when its filename matches the coordinate being resolved. That prevents
.pomfiles from being hashed as jars while still allowing real jar artifacts, including classified jars such asjar:unshaded, to be pinned and consumed normally.