kind: Kind build broken


# sigs.k8s.io/kind/pkg/kustomize
../../sigs.k8s.io/kind/pkg/kustomize/kustomize.go:108:7: undefined: k8sdeps.NewFactory
../../sigs.k8s.io/kind/pkg/kustomize/kustomize.go:109:26: not enough arguments in call to build.NewCmdBuild

Probably caused by removal of vendor.,

What happened:

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

kind version: (use kind version):
Kubernetes version: (use kubectl version):
Docker version: (use docker info):
OS (e.g. from /etc/os-release):

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 27 (19 by maintainers)

Commits related to this issue

Build of sigs.k8s.io/kind now requires gomodules https://github.com/kubernetes-sigs/kind/issues/509 — committed to fluxcd/flux by hiddeco 5 years ago
Build of sigs.k8s.io/kind now requires gomodules https://github.com/kubernetes-sigs/kind/issues/509 — committed to fluxcd/flux by hiddeco 5 years ago
Build of sigs.k8s.io/kind now requires gomodules https://github.com/kubernetes-sigs/kind/issues/509 — committed to fluxcd/flux by hiddeco 5 years ago
Build of sigs.k8s.io/kind now requires gomodules https://github.com/kubernetes-sigs/kind/issues/509 — committed to fluxcd/flux by hiddeco 5 years ago
Build of sigs.k8s.io/kind now requires gomodules https://github.com/kubernetes-sigs/kind/issues/509 — committed to fluxcd/flux by hiddeco 5 years ago

Most upvoted comments

Thanks for updating README - but I don’t think ‘go mod vendor’ is such a huge burden and will allow more people to use or test master and keep ‘go get’ working.

That is true, the burden isn’t the concern so much as the git bloat. go get with a module aware go without any options should work once we have another tag. (see below) The ecosystem has moved this way, all supported go versions support this, and we have the makefile for anyone without new enough go.

0.2.1 is from Mar 27 - and it seems Kind is evolving quite rapidly.

Yes, but we have intentionally not tagged a release while we finish making sure the changes are ironed out. Releases should “just work”. The next one will be between now and KubeCon (end of next week) if we can finish ensuring the changes are good to go.

We aim for ~monthly releases currently. We’re slightly overdue due to trying to finish ironing out the breaking image improvements. It should work much faster,

We have a similar problem in Istio with master not being stable, so I can’t complain much - but at least we try to keep it compiling. And we have quite a few debates about doing unstable development on a dev branch, and keeping master always stable and releasable.

I will again point out that master did and always has compiled, and in fact passed conformance against Kubernetes 1.12, 1.13, 1.14, and master (and until recently 1.11, but kubernetes stopped supporting it) we have pretty thorough CI. All PRs must pass this.

Master is “unstable” in that we don’t have the resources to fully guarantee it. Releases get a little extra QA. EG we do not have access to Windows CI, but we test there before releasing. Most of this is just me 😃

We did however break the node image format between releases, and we changed some implementation details of the node. We make no guarantees about this yet, kind is alpha. We’re pushing to figure out what changes to make on the way to beta and GA/stable.

BenTheElder on May 9, 2019