🌱 verify go modules are in sync with upstream k/k

[alexandremahdhaoui]

This PR should address the following issue #2769.

Changes

• add gomodcheck:
  • Parse and compares k/k direct dependencies to controller-runtime's direct deps.
  • If any version diffs is found, returns a payload describing the diffs and exit 1.
  • The user may exclude packages by passing them as arguments.
• add gomodcheck to the verify-modules make target.

Fixes #2769

[k8s-ci-robot]

Hi @alexandremahdhaoui. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[alexandremahdhaoui]

Here is a list of currently out of sync dependencies:

{
  "outOfSyncModules": [
    {
      "name": "github.com/prometheus/client_golang",
      "version": "v1.17.0",
      "upstreamVersion": "v1.16.0"
    },
    {
      "name": "github.com/prometheus/client_model",
      "version": "v0.4.1-0.20230718164431-9a2bf3000d16",
      "upstreamVersion": "v0.4.0"
    },
    {
      "name": "golang.org/x/sys",
      "version": "v0.19.0",
      "upstreamVersion": "v0.18.0"
    },
    {
      "name": "go.uber.org/zap",
      "version": "v1.27.0",
      "upstreamVersion": "v1.26.0"
    },
    {
      "name": "sigs.k8s.io/yaml",
      "version": "v1.4.0",
      "upstreamVersion": "v1.3.0"
    }
  ]
}

[sbueringer]

/ok-to-test

[sbueringer]

Looks like we can downgrade go.uber.org/zap, golang.org/x/sys, sigs.k8s.io/yaml

I assume this is also what we would want to do to play it absolutely safe (consumers of CR can still bump to higher versions if they are sure).

Not sure what is going on with the prometheus/client_* libs. go mod tidy automatically bumps them. I think that is also how I somehow downgraded to the wrong version after bringing them in sync with k/k on my last PR. Have to take a closer look.

EDIT: Turns out I just also had to downgrade github.com/prometheus/common v0.45.0 (which was an indirect dependency bumped by one of the bump PRs)

(cc @vincepri @alvaroaleman)

[sbueringer]

PR to fix the current open findings: #2776

[alexandremahdhaoui]

The modules listed below are now flagged as out of sync:

{
  "outOfSyncModules": [
    {
      "name": "github.com/go-logr/logr",
      "version": "v1.4.1",
      "upstreams": [
        {
          "ref": "k8s.io/utils",
          "version": "v1.2.0"
        }
      ]
    },
    {
      "name": "k8s.io/klog/v2",
      "version": "v2.120.1",
      "upstreams": [
        {
          "ref": "k8s.io/utils",
          "version": "v2.80.1"
        }
      ]
    }
  ]
}

[sbueringer]

Did I understand this correctly that we are now finding inconsistencies between our dependencies?

E.g.

• k8s.io/klog/v2
  • we use: v2.120.1
  • k/k uses: v2.120.1 (I'm aware there is no "k/k" go module :))
  • k8s.io/utils v0.0.0-20230726121419-3b25d923346b uses v2.80.1

Given that we are using the same k8s.io/utils as k/k go.mod I don't think it's fixable for us to ensure all of these dependencies sync up.

I think we have to restrict the dependencies we go through (e.g. focusing on that some "core/main" k/k modules are in sync with us, like k8s.io/client-go)

We shouldn't become responsible to ensure that all k/k dependencies are using the same transitive dependencies

[sbueringer]

@vincepri I think this is a consequence of now looking at the go mod graph instead of looking at the k/k go.mod file. WDYT? (I would suggest to just compare dependencies between CR and a few "main/core" go modules of k/k)

[alexandremahdhaoui]

Edit: NVM, we can just remove k8s.io/utils from the upstreamRefs in hack/.gomodcheck.yaml

[alexandremahdhaoui]

NB: I was wondering if it can be considered okay if I create a personal repo to write an enhanced version of gomodcheck and release it there? The tool can be useful and re-used for other projects.

[sbueringer]

NB: I was wondering if it can be considered okay if I create a personal repo to write an enhanced version of gomodcheck and release it there? The tool can be useful and re-used for other projects.

Definitely okay to do that, but we're very hesitant to add dependencies to personal repos. So we would continue to use our local version I think

[sbueringer]

@alexandremahdhaoui I tried to use it on top of #2786 and I'm getting some strange results:

 make verify-modules
go mod tidy
cd hack/tools; go mod tidy
cd /Users/buringerst/code/src/sigs.k8s.io/controller-runtime/tools/setup-envtest; go mod tidy
cd /Users/buringerst/code/src/sigs.k8s.io/controller-runtime/examples/scratch-env; go mod tidy
/Users/buringerst/code/src/sigs.k8s.io/controller-runtime/hack/tools/bin/gomodcheck /Users/buringerst/code/src/sigs.k8s.io/controller-runtime/hack/.gomodcheck.yaml
{
  "outOfSyncModules": [
    {
      "name": "k8s.io/api",
      "version": "v0.30.0",
      "upstreamVersion": "v0.0.0"
    },
    {
      "name": "k8s.io/client-go",
      "version": "v0.30.0",
      "upstreamVersion": "v0.0.0"
    },
    {
      "name": "github.com/onsi/gomega",
      "version": "v1.32.0",
      "upstreamVersion": "v1.31.0"
    },
    {
      "name": "k8s.io/component-base",
      "version": "v0.30.0",
      "upstreamVersion": "v0.0.0"
    },
    {
      "name": "github.com/onsi/ginkgo/v2",
      "version": "v2.17.1",
      "upstreamVersion": "v2.15.0"
    },
    {
      "name": "k8s.io/apiextensions-apiserver",
      "version": "v0.30.0",
      "upstreamVersion": "v0.0.0"
    },
    {
      "name": "k8s.io/apimachinery",
      "version": "v0.30.0",
      "upstreamVersion": "v0.0.0"
    },
    {
      "name": "k8s.io/apiserver",
      "version": "v0.30.0",
      "upstreamVersion": "v0.0.0"
    }
  ]
}
make: *** [verify-modules] Error 1

[alexandremahdhaoui]

@sbueringer it looks like you cherry-picked an old commit of this branch.
NB: I've rebased onto main and tests pass.

[sbueringer]

Overall looks good. Just a few smaller findings

[sbueringer]

Very nice. Thank you!

/lgtm
/approve

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 3881f0ce785eddfc99d0a4fd7e16a93444ea8bd9

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alexandremahdhaoui, sbueringer

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [sbueringer]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment