decentralize osde2e tests

[jbpratt]

• Boilerplate: Update to 764036b2bf3138ef860fa07d8e0cc017c8cfca43
• osde2e: migrate tests

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: jbpratt
Once this PR has been reviewed and has the lgtm label, please assign maorfr for approval. For more information see the Kubernetes Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[openshift-ci]

Hi @jbpratt. Thanks for your PR.

I'm waiting for a app-sre 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.

[jbpratt]

/assign @ryankwilliams @ritmun

Hi @tremes @JoaoFula, sorry for the delay on this PR. This is ready for review/discussion on moving forward. I've subscribed to the osde2e boilerplate but if that isn't desired, I can unwire that stuff and just bring in the tests themselves. To run locally, you can modify the osde2e/deployment_validation_operator_runner_test.go like below then run the test using ginkgo run ./osde2e/ -vv --poll-progress-after=1m

diff

diff --git a/osde2e/deployment_validation_operator_runner_test.go b/osde2e/deployment_validation_operator_runner_test.go
index 804a496..5f64ebc 100644
--- a/osde2e/deployment_validation_operator_runner_test.go
+++ b/osde2e/deployment_validation_operator_runner_test.go
@@ -1,28 +1,15 @@
-// THIS FILE IS GENERATED BY BOILERPLATE. DO NOT EDIT.
-//go:build integration
-// +build integration
-
 package osde2etests

 import (
-       "path/filepath"
        "testing"
+
        . "github.com/onsi/ginkgo/v2"
        . "github.com/onsi/gomega"
 )

-const (
-       testResultsDirectory = "/test-run-results"
-       jUnitOutputFilename  = "junit-example-addon.xml"
-)
-
 // Test entrypoint. osde2e runs this as a test suite on test pod.
 func TestDeploymentValidationOperator(t *testing.T) {
        RegisterFailHandler(Fail)

-       suiteConfig, reporterConfig := GinkgoConfiguration()
-       reporterConfig.JUnitReport = filepath.Join(testResultsDirectory, jUnitOutputFilename)
-       RunSpecs(t, "Deployment Validation Operator", suiteConfig, reporterConfig)
-
+       RunSpecs(t, "Deployment Validation Operator")
 }
-

hope this helps :)

[tremes]

Thanks a lot @jbpratt. What is the advantage of subscribing to osde2e boilerplate please? I will try to review ASAP. I would love to see this running as a prow CI check here :) but that would be probably next step.

[jbpratt]

Thanks a lot @jbpratt. What is the advantage of subscribing to osde2e boilerplate please? I will try to review ASAP. I would love to see this running as a prow CI check here :) but that would be probably next step.

@tremes The osde2e boilerplate is just to make our lives easier when decentralizing the tests to have a common pattern with building and publishing the tests as a container image to be consumed by osde2e. Since DVO isn't an SRE-P operator, I don't think we really care either way. I'm just not sure if DVO is meant to continue running in our pipelines (I'm lacking information around why or why not :). If that is the case, I don't think it makes too much sense to subscribe and bring in all of these files which won't be used but I want to leave that up to you all. I prefer using ginkgo directly which would simplify development and execution IMO. There is also support gaining to the step registry for deploying managed clusters which we have been exploring as an alternative to using OSDE2E to launch clusters but I think DVO is flexible enough to test wherever so this may not be a concern. I will chat with my team to see if they have an opinions either way!

[ritmun]

Left a couple of comments related to bp update. Just saw your comment above. Do whatever's best depending on the conclusion.

[ritmun]

This version of dockerfile won't run correctly. I suggest a bp-update and e2e-harness-generate.

[ritmun]

This function should be suffixed with "Test" otherwise the suite complains about no tests being found. A bp-update and harness-generate will fix this issue as well.

[jbpratt]

/close in favor of #243