8000 Operator Helm chart renders null version labels because Chart.yaml lacks appVersioN · Issue #53804 · keycloak/keycloak · GitHub
[go: up one dir, main page]

Skip to content

Operator Helm chart renders null version labels because Chart.yaml lacks appVersioN #53804

Closed

Description

@jkleinlercher

Before reporting an issue

  • I have read and understood the above terms for submitting issues, and I understand that my issue may be closed without action if I do not follow them.

Area

operator

Describe the bug

The official chart oci://quay.io/keycloak/keycloak-operator-helm:26.8.0 renders app.kubernetes.io/version as YAML null on controller RoleBindings.

The published Chart.yaml does not define appVersion, but the affected templates reference .Chart.AppVersion without quoting or a fallback.

In our Argo CD deployment, this caused persistent OutOfSync status. Enabling ServerSideApply=true alone did not resolve it. Adding argocd.argoproj.io/compare-options: ServerSideDiff=true resolved the comparison issue, but the chart still emits the null-valued label.

Additional context

The chart is generated by the Quarkus Helm extensions:

https://github.com/keycloak/keycloak/blob/26.8.0/operator/README.md#helm-chart

The generation configuration does not set quarkus.helm.app-version:

https://github.com/keycloak/keycloak/blob/26.8.0/operator/src/main/resources/application.properties

Our integration PR contains the rendered-chart output:

suxess-it/kubriX#3053 (comment)

A related Argo CD issue describes persistent diffs for null-valued ConfigMap entries. It concerns the same general failure class, rather than this exact RoleBinding:

argoproj/argo-cd#15566

Version

26.8.0 — official keycloak-operator-helm OCI chart.

Regression

  • The issue is a regression

Expected behavior

The version label should contain the operator release version, for example "26.8.0", or be omitted when no version is available.

Actual behavior

We inspected the published chart archive directly. Its Chart.yaml contains:

name: keycloak-operator-helm

type: application

version: 26.8.0

There is no appVersion field.

Both these templates reference .Chart.AppVersion:

  • templates/keycloakcontroller-crd-role-binding.yaml

  • templates/keycloakoidcclientcontroller-crd-role-binding.yaml

app.kubernetes.io/version: {{ .Chart.AppVersion }}

The namespace-list branch uses {{ $.Chart.AppVersion }} with the same result.

The rendered resource includes:

apiVersion: rbac.authorization.k8s.io/v1

kind: RoleBinding

metadata:

  name: keycloakcontroller-role-binding

  namespace: keycloak

  labels:

    app.kubernetes.io/name: keycloak-operator

    app.kubernetes.io/version:

    app.kubernetes.io/managed-by: quarkus

The unquoted blank value is YAML null, rather than an empty string.

How to Reproduce?

Inspect the chart metadata:

helm show chart oci://quay.io/keycloak/keycloak-operator-helm \

  --version 26.8.0

Render the affected RoleBinding:

helm template keycloak-operator \

  oci://quay.io/keycloak/keycloak-operator-helm \

  --version 26.8.0 \

  --namespace keycloak \

  --set-string operator.envs.QUARKUS_OPERATOR_SDK_CONTROLLERS_KEYCLOAKCONTROLLER_NAMESPACES=JOSDK_WATCH_CURRENT \

  --show-only templates/keycloakcontroller-crd-role-binding.yaml

Observe that app.kubernetes.io/version: has no value.

The inspected chart layer has digest:


sha256:103112ad95c69550032c45a3e7f93f38ae5c50b53f06d2e00b9e57a72a4904b9

Anything else?

Suggested fix:

Populate quarkus.helm.app-version from the actual release version during chart generation, so the published Chart.yaml contains:

appVersion: "26.8.0"

The templates could additionally guard against a missing version.

Activity

  1. added theissue type on Oct 9, 2026
  2. added
    area/operatorKeycloak Operator — Kubernetes/OpenShift deployment, CRDs, Helm charts
    on Oct 9, 2026
  3. KyriosGN0 commented on Oct 10, 2026

    @KyriosGN0
    Contributor

    Hey @shawkins @vmuzikar i believe this can be solved in the github workflow that publishes the chart, just need to also pass -Dquakus.helm.app-version same as here, im not sure if the keycloak-rel github can accept contributions from outside keycloak, if it does and its ok with you i will send a PR for this

  4. shawkins commented on Oct 12, 2026

    @shawkins
    Contributor

    @KyriosGN0 there's a whole process to getting keycloak-rel PRs committed, so I'll make this change.

  5. 10 remaining items

  6. added a commit that references this issue on Oct 14, 2026
    8a081db
  7. added a commit that references this issue on Oct 15, 2026
    419bd23
  8. added a commit that references this issue on Oct 15, 2026
    e8e8a65
  9. added 2 commits that reference this issue on Oct 22, 2026
    f1481a5
    549bd30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    Fields

    No fields configured for bug.

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    0