Upgrade ginkgo to v2 for go/v4 plugin

[haoxins]

trafficstars

What do you want to happen?

I just submitted a PR for upgrading ginkgo to v2, see https://github.com/kubernetes-sigs/kubebuilder/pull/2522 After some discussions we found it's a broken change for go/v3. So I created this issue for tracking the upgrade and intend to be added to v4 milestone.

Extra Labels

No response

[camilamacedo86]

We checked in the review of https://github.com/kubernetes-sigs/kubebuilder/pull/2522 that changes in the scaffolds are required and that the previous code will not work with ginkgo v2 so it is a breaking change and then we cannot move forward in go/v3. We will need a go/v4 plugin to add this one.

See that the scaffolds require to be changed with the following migrations.

• https://onsi.github.io/ginkgo/MIGRATING_TO_V2#generating-custom-reports-when-a-test-suite-completes
• https://onsi.github.io/ginkgo/MIGRATING_TO_V2#removed-async-testing

Also, you can check the policy: https://github.com/kubernetes-sigs/kubebuilder/blob/master/VERSIONING.md#introducing-changes-to-plugins

[camilamacedo86]

Besides the ginkgo upgrade is considered a breaking change because requires small changes Kubebuilder has k8s and controller-runtime as a dependency. Therefore, k8s 1.25 made this change and we have a PR open to introducing it in controller-runtime (see https://github.com/kubernetes-sigs/controller-runtime/pull/1977).

In this way, we need to be aligned with both and the best approach seems to ensure that Kubebuilder tests as go/v3 and go/v4-alpha are all updated to using ginkgo v2.

On top of that following further details were provided by @jakobmoellersap:

With the Migration of Gingko in controller-runtime (see https://github.com/kubernetes-sigs/controller-runtime/pull/1977) we will also have the chance to migrate our test coding as well as our templated scaffolds to gingko v2. To make sure that we do not break incompatibility, we especially need to look at the migration guide in https://onsi.github.io/ginkgo/MIGRATING_TO_V2

Since CR is upgrading this also means we have to react to the resulting breaking changes EDIT: This is not a breaking change anymore after the removal of the changes of the printer package

The PR removes two helpers in pkg/envtest/printer that were used with ginkgo v1. Since you can't use both versions at the same time, this isn't relevant though. In summary, all projects depending on controller-runtime will have to update to ginkgo v2 after this is merged and released. Upstream did so already: https://github.com/kubernetes/kubernetes/pull/109111

[jakobmoellerdev]

/assign

[camilamacedo86]

We update the CLI: https://github.com/kubernetes-sigs/kubebuilder/pull/2876 However, we need to update the scaffolds. Also, since C+R and k8s made the update and their a dep we probably need to ensure the same for all scaffolds indeed go/v3

[camilamacedo86]

Hi @jakobmoellersap,

Are you able to help us update the scaffolds by doing the same changes in the scaffolds so we are able to do a new release with this change?

[jakmoe]

Yup, was out the last few days. Will submit a draft today.

[camilamacedo86]

Done.