Conversation
|
You can test the changes on this Pull Request by downloading the APK here. |
.github/dependabot.yml
Outdated
| version: 2 | ||
| updates: | ||
| - package-ecosystem: "gradle" | ||
| open-pull-requests-limit: 2 |
There was a problem hiding this comment.
I've limited number of opened PRs 2 to prevent being flood by them.
There was a problem hiding this comment.
Does that mean that the bot will only open 2 PRs max… per day (so if there are 5 outdated deps, it will open 2 PRs on first run on day 1, 2 others on day 2 and one last on day 3)? Or 2 max total (so will creat 2 PRs on day one but will then not open new ones until we close/merge those 2 and have less than 2 still open)?
Depending on this, as well as the average number of issues that Dependabot is gonna find every time, not sure it's worth limiting?
There was a problem hiding this comment.
Or 2 max total (so will create 2 PRs on day one but will then not open new ones until we close/merge those 2 and have less than 2 still open)
exactly this ☝️
not sure it's worth limiting?
If we would merge this without limiting, we would end up with having max 5 PRs open at a time as it's a default limit provided by Dependabot.
We could remove limit by setting some big number as a limit as I did in the test run but this would ended up with more than 40 PRs opened at a time - I'm worried that this could shadow the feature PRs.
I'd opt to limit the number of PRs but I'm ok with increasing this number to some bigger than 2. WDYT @AliSoftware ?
There was a problem hiding this comment.
Wow 40 is a lot indeed. Worth limiting. Maybe default of 5 is OK though.
What happens if Dependabot opens a PR to update dependency X to version 1.2.3, but we don't wrangle it right away and let it rot… and then later dependency X requires yet another update to 1.3.4? Does Dependabot update the still-open PR? (Or closes the old one and create a new one, tomato tomahto)? Or does it keeps adding PRs without closing obsolete ones?
Because maybe today we should update 40 dependencies (number of PRs Dependabot would open without limiting) but that's because it's the start and once we start having this bot in place inviting us to update deps more regularly we won't have that many in the long run?
Anyway, regardless of the answer to ☝️, 5 seems like a good compromise of a limit to me; we can always revisit later anyway.
There was a problem hiding this comment.
I'm more inclined to keep it as 2 for the first weeks, to give us a good chance to properly test the process, and see how it goes, then we can increase it when we are more comfortable.
There was a problem hiding this comment.
Maybe default of 5 is OK though.
Sure!
What happens if Dependabot opens a PR to update dependency X to version 1.2.3, but we don't wrangle it right away and let it rot… and then later dependency X requires yet another update to 1.3.4?
That's a good question - it's the second part you mention: Dependabot will close the old PR and open a new one. Sample of closed PR is here wzieba#50
once we start having this bot in place inviting us to update deps more regularly we won't have that many in the long run?
Yes, I hope so! 5 sounds like a good compromise to me too, I'll update PR
edit: I'm both ok with either 2 either 5 open PRs, let's see what other team members will say
| reviewers: | ||
| - "woocommerce/android-developers" |
There was a problem hiding this comment.
Every PR created by Dependabot will have the team as a reviewers - this aligns to the current reviewing process of any other PR.
There was a problem hiding this comment.
Because it's dependency-related and security-related, we might want to add @woocommerce/platform-9 team as reviewer of those too 🙂
There was a problem hiding this comment.
Sure, that's good idea thanks! Addressed in 06ee32d
| reviewers: | ||
| - "woocommerce/android-developers" | ||
| ignore: | ||
| - dependency-name: "com.android.tools.build:gradle" |
There was a problem hiding this comment.
AGP is a dependency we'd like to have in sync with other in-house libraries due to compatibility with composite builds. Dependabot will ignore any updates for that.
There was a problem hiding this comment.
First of all: wise idea, thank you! 🙇♂️
Second: the comment in the PR would be useful in the configuration file, too. What do you think of:
| - dependency-name: "com.android.tools.build:gradle" | |
| # The Android Gradle Plugin is a dependency we'd like to have in sync with other | |
| # in-house libraries due to compatibility with composite build. | |
| - dependency-name: "com.android.tools.build:gradle" |
I expanded AGP, which might be unnecessary given this file will be touched by mostly Android developers. Still, it took me a few moments to understand what AGP meant so at least one developer, future me, would benefit from this longer comment 😄
There was a problem hiding this comment.
Sure thing, good suggestion! Yeah AGP is probably not a very common shortcut, sorry for confusion 😅 addressed in fe9503f
There was a problem hiding this comment.
Still, it took me a few moments to understand what AGP meant so at least one developer
Make it two 😆 (took me a few seconds before I figured that AGP was probably an acronym for Gradle then Googled it to confirm the full name of that tool and get the abbreviation 😜 )
hichamboushaba
left a comment
There was a problem hiding this comment.
LGTM, let's give the others a chance to review it before merging it.
AliSoftware
left a comment
There was a problem hiding this comment.
Thanks for doing this, that's a great idea!
PR LGTM, so I'm ok if you want to merge it as is. Left a question + suggestion about adding P9 as reviewers but feel free to take it or leave it.
|
I'm code-freezing 6.2 today, so since this one is not urgent nor linked to any specific feature, I'm moving its milestone to 6.3 🙂 |
Description
This PR adds
Dependabottool configuration. It'll start working after merge.Resolves #3652
Update release notes:
RELEASE-NOTES.txtif necessary.