Thanks for the info, I was referrering to the inconsistency running this (with k8s.io/cli-runtime v0.19.0) ->

import "k8s.io/cli-runtime/pkg/kustomize"
..

kustomize.RunKustomizeBuild(...)

Because it's failing for the field envs and only accepts env, and on the other hand the kustomize CLI (3.8.2) it's using the correct field envs.

So I'm not completely sure that the issue you mentioned will fix this.

Hello,

It seems that the latest version of kustomize CLI (3.8.2) requires for the field envs in a secretGenerator a list of the possibles files. And the latest version of this pkg, requires for that field, the property env with a string.

It would be nice if this pkg is aligned with the cli, and I can work on a PR if that's ok.

Hi,

In the SecretGenerator's docs there's a field called env that apparently can be used for data entries.

Although , running the kustomize build via CLI (v3.8.1) for this yaml produces this error -> Error: json: unknown field "env

resources:
- deployment.yaml
- service.yaml
- hpa.yaml

secretGenerator:
- name: env-api-secrets-platform-deployment
  env: envs.txt
  type: Opaque

And running it via golang API programatically :

       var kustomizeOutput bytes.Buffer
	if err := kustomize.RunKustomizeBuild(&kustomizeOutput, fs.MakeRealFS(), path); err != nil {
		return nil, errors.Wrapf(err, "failed to run kustomize build over path: %s", path)
	}

, it works fine with these versions (go.mod) :

	sigs.k8s.io/kustomize/api v0.5.1 // indirect
	sigs.k8s.io/kustomize/kyaml v0.7.0

ah my bad, the issue should have been opened here https://github.com/kubernetes/cli-runtime

ok makes sense.

And Do you happen to know why calling the API directly with kustomize.RunKustomizeBuild is also failing for envs?

I have the same error, in mac osx and version 0.3.0 and I think is due to a bad kube config, so I've created a PR to avoid the panic and the error is showing up like:

> ./bin/kubent                                                                                                                                                                                (use1-test-4/default)
3:32PM INF >>> Kube No Trouble `kubent` <<<
3:32PM INF version dev (git sha dev)
3:32PM INF Initializing collectors and retrieving data
3:32PM ERR Failed to initialize: <nil> error="invalid configuration: [context was not found for specified context: test-cluster, cluster has no server defined]"
3:32PM ERR Failed to initialize: <nil> error="invalid configuration: [context was not found for specified context: test-cluster, cluster has no server defined]"
3:32PM ERR Failed to initialize: <nil> error="invalid configuration: [context was not found for specified context: test-cluster, cluster has no server defined]"
3:32PM INF Loaded ruleset name=deprecated-1-16.rego
3:32PM INF Loaded ruleset name=deprecated-1-22.rego

https://github.com/doitintl/kube-no-trouble/issues/25

The latest release is v1.2.0 ( on 23 Aug 2018 ) and it has not got all the master changes. Is it possible to create a new release with all the master changes?

Hi,

I'm using the kustomize golang API programatically with these versions (go.mod) :

	sigs.k8s.io/kustomize/api v0.5.1 // indirect
	sigs.k8s.io/kustomize/kyaml v0.6.0

And I've observed that is still using the old env field for SecretGenerator, because setting it like the list envs within the kustomization.yaml produces the error json: unknown field "envs", but setting it like env: envs.txt it works perfectly.

commonLabels:
  app.kubernetes.io/name: platform-test
  owner: platform-sre-eng

resources:
- deployment.yaml
- service.yaml
- hpa.yaml

secretGenerator:
- name: blabla
  envs:
  - envs.txt
  type: Opaque

Running it with the cli (v3.8.1) the opposite happens, working for the envs list and failing for the env property (which I think it's the proper way).

I think this is the latest version, so it would be nice if it can be aligned with the cli. I can work on a PR if that's ok.