--helm-extra-args are not passed through to helm init

[chrisob]

Is this a request for help?: No.

---

Is this a BUG REPORT or FEATURE REQUEST? (choose one): Bug report.

Version of Helm and Kubernetes: helm version:

Client: &version.Version{SemVer:"v2.13.1", GitCommit:"618447cbf203d147601b4b9bd7f8c37a5d39fbb4", GitTreeState:"clean"}

kubectl version:

Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.1", GitCommit:"b7394102d6ef778017f2ca4046abbaa23b88c290", GitTreeState:"clean", BuildDate:"2019-04-08T17:11:31Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"}

ct version:

Version:	 v2.3.3
Git commit:	 e3c32f5aea280676e8dc020ac1fac66bf31c7986
Date:		 2019-04-25T17:30:04Z
License:	 Apache 2.0

What happened: When the --helm-extra-args flag is set, the value is not passed through to the exec of helm init.

What you expected to happen: I would expect that --helm-extra-args is also passed through to helm init.

How to reproduce it (as minimally and precisely as possible): My ct.yaml:

debug: true
remote: origin
target-branch: master
chart-dirs:
  - charts
helm-extra-args: --stable-repo-url https://my-internal-helm-mirror/stable/

Output when running ct lint --config test/ct.yaml --chart-yaml-schema test/chart_schema.yaml --lint-conf test/lintconf.yaml:

Linting charts...
Using config file:  test/ct.yaml
------------------------------------------------------------------------------------------------------------------------
 Configuration
------------------------------------------------------------------------------------------------------------------------
Remote: origin
TargetBranch: master
BuildId: 
LintConf: test/lintconf.yaml
ChartYamlSchema: test/chart_schema.yaml
ValidateMaintainers: true
ValidateChartSchema: true
ValidateYaml: true
CheckVersionIncrement: true
ProcessAllCharts: false
Charts: []
ChartRepos: []
ChartDirs: [charts]
ExcludedCharts: []
HelmExtraArgs: --stable-repo-url https://my-internal-helm-mirror/stable/
HelmRepoExtraArgs: []
Debug: true
Upgrade: false
SkipMissingValues: false
Namespace: 
ReleaseLabel: 
------------------------------------------------------------------------------------------------------------------------
>>> git rev-parse --is-inside-work-tree
>>> git merge-base origin/master HEAD
>>> git diff --find-renames --name-only 274897e87a4b68277f3ac6d41ad5c407f54215f8 -- charts

------------------------------------------------------------------------------------------------------------------------
 Charts to be processed:
------------------------------------------------------------------------------------------------------------------------
 common => (version: "0.0.5", path: "charts/common")
------------------------------------------------------------------------------------------------------------------------

>>> helm init --client-only
Creating /root/.helm 
Creating /root/.helm/repository 
Creating /root/.helm/repository/cache 
Creating /root/.helm/repository/local 
Creating /root/.helm/plugins 
Creating /root/.helm/starters 
Creating /root/.helm/cache/archive 
Creating /root/.helm/repository/repositories.yaml 
Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com 
Error: Looks like "https://kubernetes-charts.storage.googleapis.com" is not a valid chart repository or cannot be reached: Get https://kubernetes-charts.storage.googleapis.com/index.yaml: dial tcp 172.217.22.48:443: connect: connection timed out
Error linting charts: Error initializing Helm: Error waiting for process: exit status 1
------------------------------------------------------------------------------------------------------------------------
No chart changes detected.
------------------------------------------------------------------------------------------------------------------------
Exited with code 1

Anything else we need to know: Related to #33

[unguiculus]

We would have to add a separate flag for this. Looking at this, I wonder whether we should even do helm init --client-only at all and instead expect that Helm was properly initialized already.

@jlegrone @scottrigby Should we consider changing this for a v3 or rather add an additional flag?

[chrisob]

Not sure if it helps to share more about our usecase, but we're using ct in an "offline" environment, so when helm init attempts to reach out to https://kubernetes-charts.storage.googleapis.com, it will always fail.

Thus, we're always overriding the stable repo with our own internal mirror by using the flag --stable-repo-url.

I wonder whether we should even do helm init --client-only at all and instead expect that Helm was properly initialized already

I guess this would also work for us.

[jlegrone]

We could add a --skip-helm-init flag for now, and look at removing init in the next major version.

I would be in favor of removing init altogether, ~but I think that would mean users with custom helm repos would need to build their own docker images for ct rather than using ours out of the box~.

[unguiculus]

I like that idea. Why would you need a custom Docker image?

[jlegrone]

Why would you need a custom Docker image?

Never mind, I looked at the code and initializing helm is separate from adding custom repos. This should be pretty straightforward then!

[scottrigby]

I like this too https://github.com/helm/chart-testing/issues/161#issuecomment-509259684. We may want to add a deprecation message as part of that, so it's not a surprise when we remove it in the next MAJOR version

[carlosjgp]

I do have a similar problem where I'm trying to lint a chart which requires some values need to be provided by the final user of the chart so they don't have a default value and ct lint fails to lint them

------------------------------------------------------------------------------------------------------------------------
 Configuration
------------------------------------------------------------------------------------------------------------------------
Remote: origin
TargetBranch: master
BuildId: 
LintConf: /etc/ct/lintconf.yaml
ChartYamlSchema: /etc/ct/chart_schema.yaml
ValidateMaintainers: true
ValidateChartSchema: true
ValidateYaml: true
CheckVersionIncrement: true
ProcessAllCharts: false
Charts: []
ChartRepos: []
ChartDirs: [./]
ExcludedCharts: []
HelmExtraArgs: -f ./values-test.yaml
HelmRepoExtraArgs: []
Debug: false
Upgrade: false
SkipMissingValues: false
Namespace: 
ReleaseLabel: 
...
Unable to find chart on master. New chart detected.
Validating /workdir/application-chart/Chart.yaml...
Validation success! 👍
Validating maintainers...
==> Linting application-chart
[INFO] Chart.yaml: icon is recommended
[ERROR] templates/deployment.yaml: unable to parse YAML: error converting YAML to JSON: yaml: line 57: mapping values are not allowed in this context

Error: Error linting charts: Error processing charts
engine.go:159: [INFO] Missing required value: name must be set
engine.go:159: [INFO] Missing required value: name must be set
engine.go:159: [INFO] Missing required value: image.tag must be set
engine.go:159: [INFO] Missing required value: component must be set
engine.go:159: [INFO] Missing required value: partOf must be set
engine.go:159: [INFO] Missing required value: logs must be set
...

sadly I can't use this awesome tool through the GitHub actions :cry:

[carlosjgp]

I just discovered that including my file on a ci folder inside my chart folder with a file named *-values.yaml will do what I want

https://github.com/helm/charts/issues/3943

And chart-lint is using that folder https://github.com/helm/chart-testing/search?q=ciValuesPaths&unscoped_q=ciValuesPaths

Not a problem for my use case :star_struck:

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 5 days with no activity.