Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Helm3 lint fails when using Kind: List #8615

Closed
pchugh79 opened this issue Aug 19, 2020 · 11 comments · May be fixed by #8643
Closed

Helm3 lint fails when using Kind: List #8615

pchugh79 opened this issue Aug 19, 2020 · 11 comments · May be fixed by #8643
Labels
bug Categorizes issue or PR as related to a bug. Stale

Comments

@pchugh79
Copy link

pchugh79 commented Aug 19, 2020

Issues during lint with resource Kind:List - object name does not conform to Kubernetes naming requirements

Using Helm 3.3 on linux

helm lint --strict <>

apiVersion: v1
kind: List
items:
  -apiVersion: v1
  kind: ConfigMap
  metadata:
    name:  XXX  

 -apiVersion: v1
  kind: ConfigMap
  metadata:
    name:  YYY

======

Helm 2 does not fail with same resource.

@mattfarina mattfarina added question/support bug Categorizes issue or PR as related to a bug. and removed question/support labels Aug 19, 2020
@mattfarina
Copy link
Collaborator

Kubernetes objects should have a metadata section with a name property. Helm v2 did not check that names were present or valid, during lint. Helm v3 does. That is why you see that now.

List is not a resource but rather a list of resources. There is an explanation at kubernetes/kubectl#837 (comment). No official documentation exists on it.

I have not tried to send a list to Kubernetes. If it works we should handle linting that case.

@pchugh79
Copy link
Author

pchugh79 commented Aug 19, 2020

Yes Kind:List works on Kubernetes , and if i do upgrade or install with Helm3.3 it works, its just that the lint fails on linux only.
We have also observed that, Helm 3.3 lint does not fail on windows for Kind:List

@mattfarina
Copy link
Collaborator

That being the case on Windows is surprising. We'll need to look into it. Thanks for that piece of detail.

@wawa0210
Copy link
Contributor

/assign
I can try to dig deeper

@dbluxo
Copy link

dbluxo commented Aug 20, 2020

Hello, since Helm 3.3.0 I have problems with liniting the following resource:

{{- if and .Values.grafana.enabled .Values.grafana.defaultDashboardsEnabled }}
{{- $files := .Files.Glob "config/grafana/default-dashboards/*.json" }}
{{- if $files }}
apiVersion: v1
kind: ConfigMapList
items:
{{- range $path, $fileContents := $files }}
{{- $dashboardName := regexReplaceAll "(^.*/)(.*)\\.json$" $path "${2}" }}
- apiVersion: v1
  kind: ConfigMap
  metadata:
    name: {{ printf "%s-%s" (include "prometheus.grafana.fullname" $) $dashboardName | trunc 63 | trimSuffix "-" }}
    labels:
      {{- if $.Values.grafana.sidecar.dashboards.label }}
      {{ $.Values.grafana.sidecar.dashboards.label }}: "1"
      {{- end }}
      app: {{ template "prometheus.grafana.fullname" $ }}
  data:
    {{ $dashboardName }}.json: {{ $.Files.Get $path | toJson }}
{{- end }}
{{- end }}
{{- end }}
 $ helm lint .
==> Linting .
[ERROR] templates/grafana/configmap-default-dashboards.yaml: object name does not conform to Kubernetes naming requirements: ""

Error: 1 chart(s) linted, 1 chart(s) failed

With Helm 3.2.4 it worked.

Is this related to this issue or should I open a separate one?

EDIT: With Helm 3.2.4 I could also lint the above mentioned resource:

apiVersion: v1
kind: List
items:
  - apiVersion: v1
    kind: ConfigMap
    metadata:
      name:  XXX  
  - apiVersion: v1
    kind: ConfigMap
    metadata:
      name:  YYY

And with Helm 3.3.0 I also get this error:

[ERROR] templates/test.yaml: object name does not conform to Kubernetes naming requirements: ""

@mattfarina
Copy link
Collaborator

@dbluxo this is related. All lists are affected. This is due to a new linting feature in Helm 3.3.0.

cbui pushed a commit to cbui/helm that referenced this issue Aug 23, 2020
Helm v2 didn't validate that resource names were valid. Helm v3
introduces this check, failing lint checks that were previously
passing.

This PR adds a check to validate metadata for a list of resources if
present, otherwise falling back to previous behavior of validating the
metadata.

Fixes helm#8615
cbui pushed a commit to cbui/helm that referenced this issue Aug 23, 2020
Helm v2 didn't validate that resource names were valid. Helm v3
introduces this check, failing lint checks that were previously
passing.

This PR adds a check to validate metadata for a list of resources if
present, otherwise falling back to previous behavior of validating the
metadata.

Fixes helm#8615

Signed-off-by: Chris Bui <christopher.d.bui@gmail.com>
cbui added a commit to cbui/helm that referenced this issue Aug 23, 2020
Helm v2 didn't validate that resource names were valid. Helm v3
introduces this check, failing lint checks that were previously
passing.

This PR adds a check to validate metadata for a list of resources if
present, otherwise falling back to previous behavior of validating the
metadata.

Fixes helm#8615

Signed-off-by: Chris Bui <christopher.d.bui@gmail.com>
cbui added a commit to cbui/helm that referenced this issue Aug 23, 2020
Helm v2 didn't validate that resource names were valid. Helm v3
introduces this check, failing lint checks that were previously
passing.

This PR adds a check to validate metadata for a list of resources if
present, otherwise falling back to previous behavior of validating the
metadata.

Fixes helm#8615

Signed-off-by: Chris Bui <christopher.d.bui@gmail.com>
@github-actions
Copy link

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

@dbluxo
Copy link

dbluxo commented Mar 17, 2021

The workaround for this is probably to configure the list with a metadata.name, then it works:

apiVersion: v1
kind: List
metadata:
  name: ZZZ
items:
  - apiVersion: v1
    kind: ConfigMap
    metadata:
      name:  XXX  
  - apiVersion: v1
    kind: ConfigMap
    metadata:
      name:  YYY

@chillb0nes
Copy link

This workaround is not always valid, please see kubernetes-sigs/kustomize#688

@prein
Copy link

prein commented Mar 28, 2024

This workaround is not always valid, please see kubernetes-sigs/kustomize#688

How is this related?

@prein
Copy link

prein commented Mar 28, 2024

It still fails with kind: ConfigMapList for me. Helm 3.14. Why is it closed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Categorizes issue or PR as related to a bug. Stale
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants