Support Helm chart

[helayoty]

As a test writer, I should be able to deploy helm charts.

Design

The framework should provide a type that allows test writers to install helm charts

type Helm []struct {
	Name                      string
	Namespace            string
        ReleaseName         string
        Version                    string
}

Type Helm should also include a method to install the helm chart

Example

func TestMain(m *testing.M){
	testenv = env.New()
	kindClusterName := envconf.RandomName("kind-with-config", 16)
	namespace := envconf.RandomName("kind-ns", 16)

	testenv.Setup(
		envfuncs.CreateKindClusterWithConfig(kindClusterName, "kindest/node:v1.22.2", "kind-config.yaml"),
		envfuncs.CreateNamespace(namespace),
	)

	testenv.Finish(
		envfuncs.DeleteNamespace(namespace),
		envfuncs.DestroyKindCluster(kindClusterName),
	)
	os.Exit(testenv.Run(m))
}

func TestHelmChart(t *testing.T) {
           helmInfo: = {
			Name: "nginx",
                         Namespace: "default",
                         ReleaseName: "nginx-stable/nginx-ingress"
                         Version: "latest"
                 }
	tests := features.New("Setup Helm Chart").
                      SetupFromHelm(func(helmInfo Helm))
                      .Feature()
		
	test.Test(t, tests )
}

[harshanarayana]

@helayoty I opened a quick POC of the changes to enable Helm support for the e2e-framework. Please let me know if you are already working on it and I will be happy to close up my PR if you have started working on this already.

[harshanarayana]

I made the support helper a little more generic and to do now just install but a simple way to wrap all commands for helm.

proc := helm.NewManager().Run(
	helm.WithMode("install"),
	helm.WithName("memcached"),
	helm.WithReleaseName("bitnami/memcached"),
	helm.WithNamespace(namespace),
	helm.WithArgs("--kubeconfig", config.KubeconfigFile()),
)

We can also write a simple wrapper to help few generic command with much simpler way to access as well. This way, one can do most of the workflow centric to helm in their test using the same framework helpers. Is this inline with what you thought about ?

cc @vladimirvivien What do you think about this model ?

[vladimirvivien]

This is interesting.
My one suggestion is that helm shoul be kept in a package that clearly indicates it's not part of the core functionality. Possibly introduce package third-party/helm.

I will add review comments on the PR directly.

[harshanarayana]

@vladimirvivien I kept the helm.go under support/helm like we did with support/kind but moving that to third_party/helm might be a good idea too. Makes the integration with other tools easier in the future. And if we do, should we define a standard interface through which we can introduce these new tool integration or is that too much of an expectation to start with and can be done at a later date ?

type Option func(*Opts)

type Opts struct {
    name string
    args []string
    argMap map[string]interface{}
}

func WithName(name string) Option {
    return func(opts *Opts) {
        opts.name = name
    }
}

func WithArgs(args ...string) Option {
    return func(opts *Opts) {
        opts.args = append(opts.args, args...)
    }
}

func WithKWArg(key string, val interface{}) Option {
    return func(opts *Opts) {
        opts.argMap[key] = val
    }
}

type Integration interface {
    Run(opts ...Option) (proc *exec.Proc, err error)
}