Directly import cert-manager in cmctl

[SgtCoDFish]

Pull Request Motivation

Related to #6047 and #6041

This PR depended on cert-manager/release#127 , which has now merged.

We want to preserve the ability for other projects to import cmctl as a module. This implies that we can't have a local filesystem replacement for the core cert-manager module in cmctl, and that cmctl must depend on an explicitly specified version of cert-manager.

Eventually we'd like cmctl to be moved to its own repo, but that's too much work right now.

Since the integration tests depend on cmctl, they also pick up an actual version of cert-manager in their go.mod file from this change. That shouldn't matter, since they still have a replace statement for cert-manager.

Kind

/kind feature

Release Note

cmctl can now be imported by third parties.

[irbekrm]

Thank you Ashley, this makes sense.
So we'll refer to a commit hash of cert-manager in cmctl and this will allow us to bundle cert-manager and cmctl under the same tag for the ease of consumption

/lgtm

[jetstack-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: irbekrm, SgtCoDFish

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 [SgtCoDFish,irbekrm]

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

[irbekrm]

/cherry-pick release-1.12

[jetstack-bot]

@irbekrm: new pull request created: #6050

In response to this:

/cherry-pick release-1.12

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.

[maelvls]

We want to preserve the ability for other projects to import cmctl as a module.

Out of curiosity, why would we need to support "importing cmctl"? (I probably missed the discussion in which this was discussed.) Do you mean that some people have the following import statement in one of their Go files:

import github.com/cert-manager/cert-manager/cmd/ctl

I can't see myself importing a CLI package 😅

Or is the intent to make it possible to use "go install"? E.g.,

go install github.com/jetstack/cert-manager/cmd/ctl@v1.12.0

If the goal is to make it "go install"-able, then this change makes sense.

[irbekrm]

@maelvls see https://github.com/golang/go/wiki/Modules#how-can-i-track-tool-dependencies-for-a-module

i.e https://github.com/cert-manager/csi-driver-spiffe/blob/main/hack/tools/tools.go#LL10C34-L10C34

[maelvls]

Ouch, I forgot about importing binary tools in go.mod to keep track of their versions. Thanks.

[munnerz]

If I want to make a change to cert-manager/cert-manager (say, adding a new function), and then also want to make use of that function in the cmctl package/module, will I need to split my PR into two to make it possible to do because of this? e.g., first PR adds the function to the cert-manager/cert-manager module, and then a second PR updates the revision pointed to here and actually makes use of the function?

As there's no way to set this string to the correct value within a single PR....

[irbekrm]

Yes, that is the case, but we want to split cmctl out anyway

At the moment it is like this because of wanting to support go install-ing this/importing it in tools