✨ Enable using setup-envtest without a separate CLI

[tomasaschan]

This implements the proposal in #2790.

The implementation is incomplete so far; opening this mostly to show my progress and solicit feedback, as well as to avoid too many conflicts with initiatives like this one.

To do:

• Copy existing implementation of supporting packages over into the main module
• Implement use in the main module
• Implement list in the main module
• Implement cleanup in the main module
• Implement sideload in the main module
• Port tests for the workflows (at least the ones that make sense)
• Clean up the setup-envtest module, removing duplicated code etc
• Remove dependency on afero
• Rebase onto whatever latest changes have happened in e.g. go.mod since I branched off
• (Optional, possibly in a later PR) Re-implement the arg parsing and help parts of the main module with something a little less home-grown, probably something like https://github.com/spf13/cobra/

[k8s-ci-robot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: tomasaschan
Once this PR has been reviewed and has the lgtm label, please assign fillzpp 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

[tomasaschan]

I will rebase this properly once #2811 merges, since I expect conflicts with that anyway.

[tomasaschan]

@sbueringer I think this is ready for an initial review now!

I still want to get rid of the dependency on afero before we merge this, so I'm keeping the PR in a draft state, but those changes should be basically independent of the major ones here. Let me know if you have any questions or would like me to somehow document the structure of the new set of packages to make reviewing easier.

[tomasaschan]

I've spent some time now trying to rebuild this without a dependency on github.com/spf13/afero, and while I was initially encouraged by the existence of testing/fstest in the standard libarry, it turns out that while the afero implements a complete file system abstraction (and implementations for the two pieces we need; an OS wrapper and an in-memory one for testing), fstest only implements file actions for a read-only file system, expecting the tests to set up the appropriate input data before executing the SUT.

While it's certainly possible to build a read/write file system abstraction (on top of fstest or standalone) that supports the operations we need for setup-envtest, I feel it's probably not worth it in maintenance cost, compared to just relying on the third-party library. afero does not change rapidly and so we're unlikely to cause dependency hell issues by taking a dependency on it.

@sbueringer What do you think?

If you agree with this assessment, I can rebase again to get the latest version bumps of everything, and then this should be ready to go!

[k8s-ci-robot]

PR needs rebase.

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-sigs/prow repository.

[sbueringer]

@tomasaschan Just a heads up. We'll merge a PR directly after 0.19 which drops the support for GCS. Basically because we wanted to do it anyway, but also to simplify maintenance & refactorings like this PR

[tomasaschan]

Thanks for the heads up!

Have you had time to review these changes, and in particular my last comment about keeping the afero dependency?

[sbueringer]

Didn't get around to it yet. Just recently found time to catch up on controller-runtime in general and this is a big PR. But I'll try to look at it soon. Definitely feel free to wait with further rebases until then

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[sbueringer]

/remove-lifecycle stale

[tomasaschan]

/lifecycle frozen

@sbueringer and potentially other maintainers: given the initial hesitation to introduce a dependency on github.com/spf13/afero and my analysis of the available options for properly testing this (see #2810 (comment)), I'd like someone to let me know what will be required for this to be merged before I undertake the non-trivial effort to rebase this.

[k8s-ci-robot]

@tomasaschan: The lifecycle/frozen label cannot be applied to Pull Requests.

In response to this:

/lifecycle frozen

@sbueringer and potentially other maintainers: given the initial hesitation to introduce a dependency on github.com/spf13/afero and my analysis of the available options for properly testing this (see #2810 (comment)), I'd like someone to let me know what will be required for this to be merged before I undertake the non-trivial effort to rebase this.

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-sigs/prow repository.