-
Notifications
You must be signed in to change notification settings - Fork 1.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
Bump poetry version from 1.8.3 to 1.8.5 #11107
Conversation
056fe5b
to
e9ef4b4
Compare
This change is required for dependabot/dependabot-core#11107
e9ef4b4
to
08b92d2
Compare
I think for the smoke tests to pass we need to merge dependabot/smoke-tests#240 first. Or is there a way to test them together? |
Probably.
For testing purposes, you can point the smoke tests workflow file at a specific branch, but then you'll need to be sure that the final PR doesn't include that custom branch name. |
I've merged the smoke test bump: |
08b92d2
to
809fd17
Compare
We grouped the Python PR's to avoid noise. However, what I've observed in practice is we (and our users) care more about staying up to date on the package managers and not so much if the internal libraries used in our helpers stay up to date. So by breaking the package managers themselves out as distinct groups, it allows us to quickly move forward on those, without getting blocked if there's a breaking change in a minor helper library. Here's an example of exactly this problem: * #11107 (comment)
We grouped the Python PR's to avoid noise. However, what I've observed in practice is we (and our users) care more about staying up to date on the package managers and not so much if the internal libraries used in our helpers stay up to date. So by breaking the package managers themselves out as distinct groups, it allows us to quickly move forward on those, without getting blocked if there's a breaking change in a minor helper library. Here's an example of exactly this problem: * #11107 (comment)
We grouped the Python PR's to avoid noise. However, what I've observed in practice is we (and our users) care more about staying up to date on the package managers and not so much if the internal libraries used in our helpers stay up to date. So by breaking the package managers themselves out as distinct groups, it allows us to quickly move forward on those, without getting blocked if there's a breaking change in a minor helper library. Here's an example of exactly this problem: * #11107 (comment)
PR #11079 is failing because of grouping. Not sure grouping is mandatory.