-
Notifications
You must be signed in to change notification settings - Fork 641
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
ci(.dependabot): stretch the open pr limits #12146
Conversation
Some dependencies are not being updated, because we have too many pull requests by Dependabot open. We'll need to make sure to close/merge pull requests earlier, but we should also avoid that we miss out on dependency upgrades. This stretches the limits as follows: - maven: 5 -> 25 - go: 5 -> 10 - gha: 5 -> 10 These are still just magic numbers, chosen at my personal whim. However, I feel that they better reflect our project. What numbers are optimal is hard to say. My thoughts are as follows: - we have many maven dependencies, we should allow many open maven pull requests - we have fewer go and gha dependencies, we don't need as many open pull requests for these dependencies There is no way to disable the limit AFAIK. Any limit is a magically chosen number. These numbers feel good to me.
Test Results1 042 files ± 0 1 042 suites ±0 1h 51m 17s ⏱️ - 5m 56s Results for commit d659ab4. ± Comparison against base commit 290e4ed. This pull request removes 593 and adds 728 tests. Note that renamed tests count towards both.
♻️ This comment has been updated with latest results. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thanks for taking care of this!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Description
Some dependencies are not being updated because we have too many pull requests by Dependabot open. We'll need to close/merge pull requests earlier, but we should also avoid missing out on dependency upgrades.
This stretches the limits as follows:
These are still just magic numbers, chosen at my personal whim. However, I feel that they better reflect our project. What numbers are optimal is hard to say. My thoughts are as follows:
There is no way to disable the limit, AFAIK.
Any limit is a magically chosen number.
These numbers feel good to me.
Related issues
NA
Definition of Done
Not all items need to be done depending on the issue and the pull request.
Code changes:
backport stable/1.3
) to the PR, in case that fails you need to create backports manually.Testing:
Documentation:
Other teams:
If the change impacts another team an issue has been created for this team, explaining what they need to do to support this change.
Please refer to our review guidelines.