-
Notifications
You must be signed in to change notification settings - Fork 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
Grouped update PR includes no details about upgrades (part 2) #9565
Comments
This appears to be caused by #9429. The ChangelogFinder is querying https://api.github.com:443/repos/aws/aws-sdk-ruby/contents/gems/aws-sdk-s3?ref=version-3 which returns an array, so dependabot-core/common/lib/dependabot/metadata_finders/base/changelog_finder.rb Lines 132 to 136 in 005dd73
@Nishnha suggestions on how to fix it? |
Same thing for us:
I guess this would be triggered for any grouped updates for ruby repos that use AWS? Maybe any dependabot upgrades for those repos? |
Thanks for tagging me. The If we want to make this even more robust we could ask what the |
Ran into this as well: (w/ Dependabot on Github Actions)
|
Should be fixed now, let me know if you're still having an issue with new PRs. |
@jakecoffman Thank you for the update. I retriggered Dependabot, causing it to perform a rebase operation on the existing grouped update PR, however, the PR description was not fixed? (Dependabot made edits to the description, but only to add/remove the ~"rebase pending" banner). I also tried using https://github.com/heroku/cheverny/network/updates/819371876 (full run retrigger via dashboard) Is it expected that existing PRs won't get fixed? I'm curious why |
Yes only new PRs will get new PR bodies, updating a PR only sends this data: dependabot-core/updater/lib/dependabot/api_client.rb Lines 65 to 67 in b7f14e3
The idea being if the dependencies haven't significantly changed the body still is correct. Otherwise it will close and open a new one:
The easiest thing you can do is close the grouped PR, it won't create any ignores for grouped PRs, then trigger another Dependabot run. It should create the PR again with metadata. |
I tried that, but when Dependabot was retriggered (via the button on https://github.com/heroku/cheverny/network/updates/5428829/jobs), the resultant job summary says:
However, opening the logs for that job I see:
(https://github.com/heroku/cheverny/network/updates/819398685) ...which suggests it thinks it did open a PR? |
Re-opening this issue since we are still investigating |
@edmorley Sorry about that, I forgot the service checks to see if an identical PR already exists (one that has the same dependencies.) I'm seeing the error It doesn't look like there's a way to have Dependabot regenerate the metadata on an existing PR for cases like this. |
This seems resolved now, thank you. |
Is there an existing issue for this?
Package ecosystem
Bundler
Package manager version
No response
Language version
No response
Manifest location and content before the Dependabot update
https://github.com/heroku/cheverny/blob/cd5532e9d949522d3dfd317b363987271fd8a8c1/Gemfile
https://github.com/heroku/cheverny/blob/cd5532e9d949522d3dfd317b363987271fd8a8c1/Gemfile.lock
dependabot.yml content
Updated dependency
No response
What you expected to see, versus what you actually saw
The Dependabot grouped PR's description does not include any information about the packages updated by the PR:
https://github.com/heroku/cheverny/pull/375
This is a regression that started about 3 weeks ago.
The fix in #9457 (comment) didn't seem to help, though there is now a stacetrace.
Native package manager behavior
No response
Images of the diff or a link to the PR, issue, or logs
https://github.com/heroku/cheverny/network/updates/818141343
Smallest manifest that reproduces the issue
No response
The text was updated successfully, but these errors were encountered: