ci: disable non-security dependabot updates

[agilgur5]

As discussed in a previous Contributor Meeting and last month on Slack.

Motivation

• most of the automated updates from dependabot cause a lot of noise and use up CI time, without adding much

  • most often are small patch updates that don't affect our usage of deps
  • some can also cause a lot of breakage when they pass CI but break something in a way that doesn't have an automated test (or has a test flake)
    • examples in this repo include fix: CI Artifact Download Timeout. Fixes #12452 #12454, build: Skip react-router-dom on dependabot #10648, Revert "chore(deps-dev): bump raw-loader from 0.5.1 to 4.0.2 in /ui (#9034)" #9041, Revert "chore(deps-dev): bump style-loader from 0.20.3 to 2.0.0 in /ui" #8839 etc
  • some can also cause lots of merge conflicts with other manual dependency updates
    • examples in this repo include build(ui): improve performance with esbuild-loader #12516 (comment), refactor(ui): replace moment-timezone with native Intl #12097 (comment), ci(deps): dedupe yarn.lock, add check for dupes #11637 (comment), etc

• instead of unnecessary automated updates, we can just manually update deps when needed (when we need a feature or patch) and set a reminder every 6 months to check in

  • IMO, I think this would actually end up as less work than monitoring all the dependabot updates

• Note that this intentionally does not impact security updates. Security updates will still happen automatically

  • per the linked docs:

    This option has no impact on security updates, which have a separate, internal limit of ten open pull requests.

    • that is why I specifically used this configuration

Modifications

Set open-pull-requests-limit: 0 in dependabot.yml for all our currently specified package ecosystems

minor style modification

• gomod section had 0 space while the rest had 2 space indentation
  • now all are 2 space consistently

Verification

GH has no way to actually test this, but this is something I previously implemented in other repos that I have maintained (example).

[terrytangyuan]

I think they are still useful though. We can catch issues earlier and disable certain dependency's upgrade when necessary.

[terrytangyuan]

most of the automated updates from dependabot cause a lot of noise and use up CI time

I am not bothered by that. The builds run on weekends and we have plenty of CI time.

[agilgur5]

I think they are still useful though.

There is a trade-off though; per my PR description, I don't think they are more useful than they are harmful or impeding.

We can catch issues earlier and disable certain dependency's upgrade when necessary.

Currently non-security updates from dependabot have a record of causing issues rather than catching them.
Disabling updates is very reactive -- we do so only after dependabot created a bug.

In previous discussions, I had also mentioned the alternatives of disabling all devDeps (only possible for NPM in our current usage as go.mod does not distinguish unfortunately) and disabling all major updates. @terrytangyuan what do you think about those alternatives?

[isubasinghe]

I am in favour of this approach as well, I think it's much safer to only update deps when it poses a security threat.

It makes updating the nix hash easier (can be done every 6 months), currently the hash is outdated because of dependabot (the hash has to be updated manually).

[juliev0]

Hey @terrytangyuan - are you okay with being the Assignee on this one?

[terrytangyuan]

Sounds good

[blkperl]

@agilgur5 do you want to try grouped updates instead? We can have dependabot update all the dependencies weekly or monthly. The reason we enabled dependabot originally is because nobody was keeping them up to date and fixing 1 year of interface changes all at once was not fun.

example:

  - package-ecosystem: "gomod"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      dependencies:
        patterns:
          - "*"
    ignore:
      - dependency-name: "k8s.io/*"
      - dependency-name: "sigs.k8s.io/*"

https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#groups

[agilgur5]

fixing 1 year of interface changes all at once was not fun.

Fundamentally, dependabot does not solve this: dependabot makes no interface changes what-so-ever.
That is in fact the problem that this PR solves, as dependabot would keep making PRs with major bumps with breaking changes but no interface changes that often resulted in breaking CI, or worse, releases, and requiring reverts.
Some of your PRs replaced dependabot PRs with breakage that fortunately were caught by CI. You still had to manually update those deps though, so the dependabot PRs did not give any benefit, and perhaps did the opposite as they all had to be manually replaced and closed with reasons etc.

And when it didn't make breaking changes but only patches or minor bumps, those were often not useful and just added noise, especially when there were test flakes.

The signal-to-noise ratio since this was implemented has been substantially higher, nearly every dep update is both useful (EoL version, CVEs, bugfixes, etc) and/or has interface changes in the same PR now. Before this the ratio was in the opposite direction, mostly noise and little signal.

do you want to try grouped updates instead?

Grouped updates don't change the above.

or monthly

Per the linked discussions, we also discussed the update frequency and had decided on every 6 months unless otherwise done earlier.