ci: check for tidied go.mod

[phm07]

This PR adds a CI check for go mod tidy as we already do in the CLI.

[jooola]

I am against enforcing this, this will lead to git conflict that will either have to be retried with renovate or resolved manually.

I prefer to be able to merge multiple dependency upgrade and tidy every once in a while.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 67.87%. Comparing base (eca3c32) to head (408c1c6).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #530   +/-   ##
=======================================
  Coverage   67.87%   67.87%           
=======================================
  Files          47       47           
  Lines        4912     4912           
=======================================
  Hits         3334     3334           
  Misses       1170     1170           
  Partials      408      408           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[phm07]

I am against enforcing this, this will lead to git conflict that will either have to be retried with renovate or resolved manually.

No, this will prevent conflicts, because the go.sum will be strictly dependent on the go.mod if you run go mod tidy. For example, if you install a dependecy, then remove it (or update a dependency, etc.) there will still be an entry in go.sum and it will not be removed.

I prefer to be able to merge multiple dependency upgrade and tidy every once in a while.

Once a dependency is merged, renovate will rebase and re-run go mod tidy on the other PRs anyway.

[jooola]

Once a dependency is merged, renovate will rebase and re-run go mod tidy on the other PRs anyway.

That's one of my points, I don't want to wait for Renovate.

[apricote]

I am also against this, but for another reason. If we always run go mod tidy we force all dependents to upgrade their dependencies as well, to the versions we have defined here.

This feels unnecessary if we do not rely on any new features of a lib (at which point go should automatically detect that it does not work and remove the old version from go.sum).

[phm07]

If we always run go mod tidy we force all dependents to upgrade their dependencies as well, to the versions we have defined here.

go mod tidy doesn't upgrade dependencies or change the Go version.
https://go.dev/ref/mod#go-mod-tidy

(at which point go should automatically detect that it does not work and remove the old version from go.sum).

Old library versions are kept in the go.sum file if you don't go mod tidy it. Just have a look at our go.sum:

...
golang.org/x/sys v0.19.0 h1:q5f1RH2jigJ1MoAWp2KTp3gm5zAGFUTarQZ5U386+4o=
golang.org/x/sys v0.19.0/go.mod h1:/VUhepiaJMQUp4+oa/7Zr1D23ma6VTLIYjOOTFZPUcA=
golang.org/x/sys v0.20.0 h1:Od9JTbYCk261bKm4M/mw7AklTlFYIa0bIp9BgSm1S8Y=
golang.org/x/sys v0.20.0/go.mod h1:/VUhepiaJMQUp4+oa/7Zr1D23ma6VTLIYjOOTFZPUcA=
golang.org/x/sys v0.21.0 h1:rF+pYz3DAGSQAxAu1CbC7catZg4ebC4UIeIhKxBZvws=
golang.org/x/sys v0.21.0/go.mod h1:/VUhepiaJMQUp4+oa/7Zr1D23ma6VTLIYjOOTFZPUcA=
golang.org/x/sys v0.22.0 h1:RI27ohtqKCnwULzJLqkv897zojh5/DwS/ENaMzUOaWI=
golang.org/x/sys v0.22.0/go.mod h1:/VUhepiaJMQUp4+oa/7Zr1D23ma6VTLIYjOOTFZPUcA=
...

[jooola]

I think the workflow in itself is also something we are against. Having this extra possibility of failing CI is annoying.

A solution in between could be to run a go mod tidy task every week and commit this. But I think a manual tidy can be done occasionally, when it needed.

Old library versions are kept in the go.sum file if you don't go mod tidy it. Just have a look at our go.sum:

I don't think we gain much by cleaning this every time, while I see a lose having to comply to the CI check every time.

[phm07]

Having this extra possibility of failing CI is annoying

The only possibility for the CI run to fail would be if you add, remove or upgrade dependencies, in which case you would want to run go mod tidy anyway. And it's not annoying, it serves the purpose of following best practices. It's the same reason we use a linter.

[jooola]

As discussed with @phm07, he is taking over the maintenance of the dependencies.

Since I'll not be the one merging the updates, I don't see any blocker for merging this.