This repository has been archived by the owner on Nov 19, 2020. It is now read-only.
Sync kubeconfig structure as part of generate #112
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
config.go
is copied fromclient-go/tools/clientcmd/api/v1/types.go
, and then modified a bit to kinda-sorta makegopkg.in/yaml.v2
happy (modified in #71 for #60, but still kinda broken #81).Since it's still broken with
gopkg.in/yaml.v2
, let's just ditch the modifications in #71, so that we can copy the file as part of generate, instead of trying to keep it in-sync manually. This has the potential to break users who usegopkg.in/yaml.v2
(and rely on no-data
fields being set in the YAML they're parsing). I figure since it's already kinda broken, most users aren't usinggopkg.in/yaml.v2
, especially since the docs point them towardgithub.com/ghodss/yaml
.When we "generate" it, put it in
./config/v1/
, to make it clear that it is a versioned type imported from client-go. I think it's cleaner that way.But, to avoid totally breaking existing users, don't entirely remove
config.go
, but replace it with a list of Go 1.9 type aliases, so thatgithub.com/ericchiang/k8s.Config
is an alias forgithub.com/ericchiang/k8s/client/v1.Config
and so on. This bumps the required Go version from 1.7 to 1.9. This bump could be avoided at the cost of breaking existing users.Alternatively, the generate script could be edited to keep it in the current package.
I'm not sure what your feelings are on breaking changes at the expense of clarity, or whether this type of change is welcome in general.