Should binaries have there own repo or how do we manage deps better?

[kubernetes-sigs]

Should binaries have there own repo or how do we manage deps better?

[BenTheElder]

imho kubetest2 should avoid taking on many dependencies in the core, after your PR it's pretty nice at:

kubetest2/go.mod

Lines 5 to 12 in ef32b5b

	require (
	github.com/octago/sflags v0.2.0
	github.com/pkg/errors v0.9.1
	github.com/spf13/cobra v1.0.0
	github.com/spf13/pflag v1.0.5
	k8s.io/klog v1.0.0
	sigs.k8s.io/boskos v0.0.0-20200710214748-f5935686c7fc
	)

If any of the in-tree sample deployers want non-trivial dependencies for their own use, we should probably make them pull that into a separate binary / module one way or another to avoid that polluting the core package.

I would hope that kubestest2-kops could e.g. shell out to kops and be in-tree without any additional dependencies, but if kops wants to import kops code inside kubetest2-kops then we should probably put it in the kops repo.
The shim / binary-plugin style mechanism is intended to make this viable.

[amwat]

That is the intention :) Ideally you can implement your own deployer out of tree and still use the end-to-end flow as long as the deployers and tester are named correctly.

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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.

[BenTheElder]

The answer for now is: they are in another repo. https://github.com/kubernetes/kops/tree/9dc910bdac92468793b4e4eff9b75524044291bd/tests/e2e/kubetest2-kops