feat: bootstrapped junit-jupiter Kubernetes module

[manusa]

Description

Follow-up on #4054 / #4008

Exposes the JUnit 5 extension in a new kubernetes-junit-jupiter artifact.

As described in #4054, this module would allow you to configure your tests like:

@KubernetesTest
@LoadKubernetesManifests("/test-data.yml")
@RequireK8sSupport(io.fabric8.knative.serving.v1.Service.class) // Optionally require support for a resource  (test env should be reliable)
@RequireK8sVersionAtLeast(majorVersion = 1, minorVersion = 16) // Optionally require a specific K8s version
class MyTest {
  KubernetesClient client;
}

Maybe we can add configuration options in the future to the @KubernetesTest annotation:

• Disable namespace creation
• Use of specific named namespace
• ...

/cc @andreaTP

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change
• Chore (non-breaking change which doesn't affect codebase;
  test, version modification, documentation, etc.)

Checklist

• Code contributed by me aligns with current project license: Apache 2.0
• I Added CHANGELOG entry regarding this change
• I have implemented unit tests to cover my changes
• I have added/updated the javadocs and other documentation accordingly
• No new bugs, code smells, etc. in SonarCloud report
• I tested my code in Kubernetes
• I tested my code in OpenShift

[sonarcloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
41 Code Smells

48.6% Coverage
0.0% Duplication

[andreaTP]

Amazing, thanks!

[shawkins]

LGTM

[metacosm]

Looks good! Maybe worth looking into adding support for this in Quarkus in a way similar to the @WithKubernetesTestServer annotation?

[manusa]

Looks good! Maybe worth looking into adding support for this in Quarkus in a way similar to the @WithKubernetesTestServer annotation?

I think for Quarkus we need to provide a specific implementation considering a use case where this client would be injected into the production code.

Anyway, for me the first step is releasing the snapshot and see what kind of usages our users make of this. In my case, I will be reusing part of this features in our jkube-integration-tests repository.

Further refinements and enhancements might include adding configuration options to the @KubernetesTest annotation:

public @interface KubernetesTest {
  /**
   * Should a namespace be created for the test and the client instance configured to use it?
   */
  boolean createNamespace() default true;
  /**
   * Fixed namespace to use instad of the UUID generated default.
   */
  String namespace();
}

But following the YAGNI principle, I think that some feedback might be better first.

Also note that the JUnit extensions should be composable (check the LoadKubernetesManifestsExtension implementation and LoadKubernetesManifests annotation). I'm commenting this especially for the JOSDK specific extension that could very well reuse the namespace creation part, and then do its own thing.

@ExtendWith({ KubernetesNamespacedTestExtension.class, OperatorExtension.class })
public @interface OperatorSdkTest {
// ....
}

[manusa]

I'm merging now so that it makes it to tonight's snapshot release