Fix Maven released? check for non-jar packaging types (e.g., aar)#14886
Draft
Fix Maven released? check for non-jar packaging types (e.g., aar)#14886
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR improves Dependabot’s Maven released? determination by handling artifacts whose published packaging type isn’t jar (e.g., aar) when the consuming POM omits <type> and the code otherwise defaults to checking a .jar URL that will 404.
Changes:
- Added a
.pomURL helper and introduced a narrow.pomfallback inreleased?when the artifact URL returns HTTP 404 and no classifier is present. - Added/updated RSpec stubs and examples to cover the new fallback behavior and keep existing “unreleased” simulations accurate.
- Updated version finder specs to stub
.pomHEAD requests in scenarios that now trigger the fallback.
Show a summary per file
| File | Description |
|---|---|
maven/lib/dependabot/maven/shared/shared_package_details_fetcher.rb |
Implements .pom URL generation and 404-only fallback logic in released? (skipping classifier cases). |
maven/spec/dependabot/maven/shared/shared_package_details_fetcher_spec.rb |
Adds focused test coverage for the .pom fallback and ensures existing 404 cases stub both artifact and pom. |
maven/spec/dependabot/maven/package/package_details_fetcher_spec.rb |
Updates unreleased-version stubs to account for the new .pom fallback path. |
maven/spec/dependabot/maven/update_checker/version_finder_spec.rb |
Updates stubs in 404 scenarios so version selection logic remains deterministic with the new fallback. |
Copilot's findings
- Files reviewed: 4/4 changed files
- Comments generated: 0
When a Maven artifact uses non-jar packaging (e.g., aar for Android libraries like grpc-cronet), but the consumer POM omits <type>, the parser defaults to "jar". This caused released?() to HEAD-check .jar URLs that return 404 for every version, wasting ~2 minutes on fruitless requests. Now, when the artifact HEAD returns 404 and no classifier is present, we fall back to checking the .pom file (which always exists for published artifacts). This correctly identifies published versions regardless of packaging type. Fixes #14843 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
3c02513 to
eeae216
Compare
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
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.
What are you trying to accomplish?
When a Maven artifact uses non-jar packaging (e.g.,
aar), but the consumer POM omits<type>, the parser defaults to"jar". This causesreleased?()to HEAD-check.jarURLs that always return 404, wasting ~2 minutes per run.For example,
io.grpc:grpc-cronetis packaged asaar— the.jarnever exists, but the.pomalways does.Now
released?falls back to a.pomHEAD check when the artifact returns 404 (only when no classifier is present).Fixes #14843
Anything you want to highlight for special attention from reviewers?
The fallback is intentionally narrow:
.pomsince every published Maven artifact has oneHow will you know you have accomplished your goal?
All related Maven tests pass (133 examples, 0 failures), including 4 new test cases covering the fallback behavior.
Checklist