Infra: Run dependabot daily for gradle, npm and docker

[yeikel]

Is there anything you'd like reviewers to focus on?

Dependencies such as Spring are highly susceptible to CVEs, so it’s important to promptly receive and merge fixes when vulnerabilities are identified. For example #1354 needed manual intervention due to this same Dependabot timing

Theoretically, Dependabot Security updates(if enabled) should be able to handle security upgrades off-the schedule. However, that heavily depends on a vetted CVE and the corresponding Dependabot alert. For new CVEs where the alert does not exist yet, this may add 2-3 days of latency

Currently, the number of Dependabot pull requests is low because of our grouping configuration, so increasing its run frequency should not create extra noise for maintainers.

I excluded GitHub actions because weekly should be fine for that ecosystem given that the CVE pressure there is low

How Has This Been Tested? (put an "x" (case-sensitive!) next to an item)

• No need to

Checklist (put an "x" (case-sensitive!) next to all the items, otherwise the build will fail)

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (e.g. ENVIRONMENT VARIABLES)
• My changes generate no new warnings (e.g. Sonar is happy)
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged

A picture of a cute animal (not mandatory but encouraged)

[Haarolean]

I don't think we need this right now. At the moment, we're limited by the number of open pull requests (30 rn) and bumping interval won't change anything unless we start to merge these PRs more often.

[yeikel]

I don't think we need this right now. At the moment, we're limited by the number of open pull requests (30 rn) and bumping interval won't change anything unless we start to merge these PRs more often.

I understand your reasoning, but I think that it'd be easier for me to tag the team in ready-to-go Dependabot security upgrades than to analyze the CVE logs, send the pull request, wait for CI and only then send the pull request for review

[Haarolean]

I don't think we need this right now. At the moment, we're limited by the number of open pull requests (30 rn) and bumping interval won't change anything unless we start to merge these PRs more often.

I understand your reasoning, but I think that it'd be easier for me to tag the team in ready-to-go Dependabot security upgrades than to analyze the CVE logs, send the pull request, wait for CI and only then send the pull request for review

If the bump is CVE-related, these rules (grouping and PR limits) are ignored and PRs are raised as a separate bumps

[yeikel]

If the bump is CVE-related, these rules (grouping and PR limits) are ignored and PRs are raised as a separate bumps

Yes, but see this point:

Theoretically, Dependabot Security updates(if enabled) should be able to handle security upgrades off-the schedule. However, that heavily depends on a vetted CVE and the corresponding Dependabot alert. For new CVEs where the alert does not exist yet, this may add 2-3 days of latency

That's why I discovered and created #1354 before the dependabot pull request was created