Add .github/dependabot.yml

[kolyshkin]

Make sure our dependencies and actions stay up to date.

PS I am not entirely sure that keeping all our go.mod dependencies
at their latest released versions is quite the right approach. Maybe
@thaJeztah have something to say about it.

[Copilot]

Pull Request Overview

This PR adds a Dependabot configuration file to help keep our dependencies and GitHub Actions up to date. Key changes include the introduction of daily update schedules for Go module dependencies and GitHub Actions workflows.

[thaJeztah]

Yeah, I'm tempted to say limiting it to updating github actions could make sense; it's good to keep the actions up-to-date, but for go.mod dependencies, I'd still consider sticking to Go's MVS (minimum version selection); if there's no reason to update the dependency, then we should specify the minimum required version for this module to do its thing (and consumers can pick whatever SemVer compatible version that's higher).

For Go versions, we could use the stable and oldstable keywords if we want to reduce maintenance; might be good to setup a scheduled job so that CI runs periodically, even if there were no changes, so test against oldest supported, oldstable, and stable ?

cgroups/.github/workflows/test.yml

Line 20 in 9657f5a

go-version: [1.23.x, 1.24.x]

I guess ideally we'd have CodeQL check for vulnerabilities in the modules we use, and it could update those dependencies, but it's likely to have false-positives (so setting up a govulncheck check would probably be better.

[tianon]

For Go versions, we could use the stable and oldstable keywords if we want to reduce maintenance; might be good to setup a scheduled job so that CI runs periodically, even if there were no changes, so test against oldest supported, oldstable, and stable ?

To that end, you might enjoy opencontainers/image-spec@00584ff 👀

[thaJeztah]

To that end, you might enjoy opencontainers/image-spec@00584ff 👀

Thanks! The go.mod could work; my consideration was that it's nowadays "easy" to accidentally update the go version in go.mod (updating a dependency may push it up), so I was considering that pinning the oldest version explicitly in the github actions workflow would make updating the minimum version a more explicit action.

[kolyshkin]

I've updated the PR to exclude go.mod updates, and added a govulncheck run
for every PR, the push on main branch, and once a week (with the rest of the checks).

[kolyshkin]

govulncheck-action is a tad rusty; filed golang/go#73616 and opened a CL to fix: https://go-review.googlesource.com/c/govulncheck-action/+/670318

[kolyshkin]

@thaJeztah PTAL

[thaJeztah]

LGTM, thanks!

[thaJeztah]

These always drive me nuts; I once wrote a nice comment to document the fields (as it's very easy to get them wrong);
https://github.com/docker/cli/blob/8b8f558b8350d80530d39cae51d4d425d381a1ef/.github/workflows/codeql.yml#L23-L33

  schedule:
    #        ┌───────────── minute (0 - 59)
    #        │ ┌───────────── hour (0 - 23)
    #        │ │ ┌───────────── day of the month (1 - 31)
    #        │ │ │ ┌───────────── month (1 - 12)
    #        │ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday)
    #        │ │ │ │ │
    #        │ │ │ │ │
    #        │ │ │ │ │
    #        * * * * *
    - cron: '0 9 * * 4'

[kolyshkin]

This used to be in crontab(5) man page, but cron is now gone from the distros in favor of systemd.timer so there's no documentation anymore).

[thaJeztah]

Yeah, I'm pretty sure I originally copied it from somewhere; could've been from the man-page for sure!

[kolyshkin]

Hmm, I dunno what to do about the new govulncheck warning, as the vulnerability is Windows-specific and this package is Linux-specific, so we're definitely not vulnerable.

The only way I see is to use latest go version so that standard library vulnerabilities will be excluded.

[kolyshkin]

Hmm, I dunno what to do about the new govulncheck warning, as the vulnerability is Windows-specific and this package is Linux-specific, so we're definitely not vulnerable.

The only way I see is to use latest go version so that standard library vulnerabilities will be excluded.

Hmm, this is actually the default way of using govulncheck-action. Let's just use it, as we're only interested in vulnerabilities in dependencies.

[thaJeztah]

@AkihiroSuda ptal