adoroszlai commented on PR #11734: URL: https://github.com/apache/ozone/pull/11734#issuecomment-6394877286
Thanks @ivandika3. > Firstly, after this patch, does dependabot only raise an PR if there is a security upgrades or does the community need to handle it ourselves? It does raise PRs for security upgrades if it can. It [reports](https://github.com/apache/ozone/security/dependabot) them privately in any case. > Also from what I gather the reason of disabling automatic dependabot update for non-security upgrades is to prevent supply chain attacks for newer dependencies? In that case, a known way is to delay any upgrades by a certain amount of time (e.g. 1-2 weeks) before upgrading. We already delay upgrades by 1 week: https://github.com/apache/ozone/blob/a5814528cdc8d3c1b27f259e0db2256b585cb825/.github/dependabot.yml#L74-L75 > I think I'm lacking context on this. Sorry, I was planning to start a discussion on `dev@`, but have not sent it yet, because there I have to start explaining from scratch. Let me post it here instead. Dependabot updates each dependency in separate PR by default, but it can be configured to group sets of dependencies. Benefits (compared to grouped PRs): - simple: less configuration - transparent: commit title says everything, CI results reflect one upgrade - may be easier to backport Problems with separate PRs: - heavy on resources - two CI runs - a cache re-build - a Jira issue - may have conflicts between its own PRs, then it needs to rebase - backport conflicts still possible, because not all dependencies' bumps should be backported - cross-dependencies need to be tweaked manually Problems with Dependabot itself: - It eagerly creates pull requests, regardless of an update's merits or compatibility. Sometimes dependencies have "no-op" releases, or come with changes irrelevant for our project. We can simply close the pull request, but it is still an unnecessary CI run. - It creates branches in the main repo for its PRs instead of using a fork. - It only updates the default branch (`master`). If older release branches are on different minor/major version of some dependency, then we need a separate change, not a simple backport. - Cooldown does not seem to work [2] the way it is described in docs [3]. It is supposed to upgrade to the current latest version _if there was no more recent release within the cooldown period_. Instead, it simply updates to the _latest version that predates the cooldown period_. So it just delays updates, does not skip them. This puts the burden on the reviewer to check if there are even newer versions than the one in the PR. - It cannot cope with multiple versions of the same dependency (e.g. Hadoop in Ozone). [Renovate](https://docs.renovatebot.com/) is a third-party tool, but free for open source projects. Apache Infra's [GitHub Actions Policy](https://infra.apache.org/github-actions-policy.html) mentions it as an alternative to Dependabot. According to the docs, it solves some problems I mentioned: - can create draft PRs - there is a version that [uses forks](https://github.com/apps/forking-renovate) - can maintain multiple branches Questions: - Should we try Renovate, or are there any other alternatives? - Should we keep independent updates with reduced frequency? Or should we have more frequent "all-dependency" updates? Something between the two, several groups, tuned separately? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
