helm: add Kubeflow Dashboard chart

[danish9039]

Summary of Changes

Adds the Kubeflow Dashboard Helm chart under applications/dashboard/helm,
co-located with the Kustomize component it wraps.

Kustomize stays the source of truth. The synchronization script builds the
platform overlay once and writes deterministic payloads under manifests/, which
small templates load with .Files.Get. Helm does not evaluate that content, so
Go template delimiters inside upstream manifests survive verbatim.

Scope is one scenario, platform, mapping to
applications/dashboard/overlays/istio.

How it works

flowchart TD
    A["applications/dashboard/overlays/istio"] --> B["one kustomize build"]
    B --> C["scripts/generate-dashboard-helm-manifests.py"]
    C --> D["validate every resource<br/>apiVersion, kind, name, no duplicates"]
    D --> E["hand-written? exclude it"]
    D --> F["CustomResourceDefinition?<br/>platform-crds.yaml + resource-policy keep"]
    D --> G["everything else<br/>platform-resources.yaml"]
    E --> H["templates/*.yaml<br/>real Helm templates with values"]
    F --> I["templates/platform.yaml<br/>.Files.Get, not evaluated"]
    G --> I
    H --> J["rendered output equals kustomize build"]
    I --> J

Loading

Two generated payloads, three extracted documents, and seven resources rendered
from hand-written templates so the values Kustomize already declares can be set
through values.yaml. Everything else is vendored verbatim.

Configuration

Every value maps to something the Kustomize baseline already declares — an
images: transformer or a configMapGenerator input — and every default equals
what applications/dashboard/overlays/istio renders. The full table is in
the chart README: image
registry and per-component repositories, the identity headers, the registration
flow and metrics toggles, the Profile Controller administrator and workload
identity, and three whole documents (links, settings, namespaceLabels) that
inherit upstream byte for byte unless replaced.

Authentication is deliberately not configured here. The login flow belongs to the
dex and oauth2-proxy charts; this chart only consumes the identity they place
in identity.userIdHeader. Replacing that login flow with a real identity
provider is #3568.

Keeping it up to date

The payloads are output, not source, and three mechanisms keep that honest —
described in
How this chart is kept up to date:

• regeneration is idempotent — the idempotence job re-runs the synchronization
  script and fails if the tree changes, so a hand-edited payload is caught;
• parity is the drift detector — the comparison job checks the committed chart
  against a fresh kustomize build, so an upstream change the chart does not
  follow turns the build red;
• excluded resources are declared — the seven hand-written resources are named
  in the generator, which refuses to run if one stops being produced by Kustomize
  rather than silently dropping it.

At release n + 10 the payloads are whatever kustomize build produced then, and
the only manual surface is those seven templates, each compared against Kustomize
on every run.

Changed since the last review

• The five-payload component classifier was removed. Resources are classified
  only as custom resource definitions or everything else, so the hand-written
  surface no longer grows with upstream.

• scripts/helm_manifest_generator.py was extracted as the shared engine,
  reused by helm: add Kubeflow Notebooks chart #3525.

• The three embedded documents are extracted verbatim into manifests/documents/
  so a hand-written template can inherit them exactly while still allowing an
  override.

• The synchronization script updates Chart.yaml and regenerates the payloads
  through the shared atomic writer, which addresses the earlier
  "You are missing the synchronization script changes".

• Custom resource definitions ship in templates/ with
  helm.sh/resource-policy: keep rather than in crds/, because Helm never
  upgrades anything in crds/. The lifecycle table is in the README.

• The routing test has been dropped. It asserted that the routing table
  contains the rows this pull request adds, which mirrors configuration rather
  than checking behaviour. The routing rows themselves are unchanged.

  For the record, this does leave one gap. If a route were deleted, the
  idempotence job would run no synchronization script and pass. For the chart and
  payload routes the Helm/Kustomize comparison still fails, because the committed
  payload would no longer match a fresh kustomize build. For the two
  generator-script routes it would not, since a change that only alters output
  formatting leaves the comparison green. Happy to add a narrow guard for those
  two if you would rather have it, though it belongs with the shared tooling
  rather than in this chart's pull request.

• Kustomize is now on PATH for the later steps in all four jobs that install it.

Dependencies

Runtime installation order follows the foundation and wrapper charts: #3468,
#3470, #3478, #3479, #3480. Render parity for this pull request is self-contained.

#3567 touches tests/helm_kustomize_compare.py and
tests/helm_kustomize_compare.sh. Whichever merges second needs a rebase.

Related Issues

Part of the Project 5 Helm chart work.

Validation

python3 -m unittest tests/test_helm_manifest_generator.py
python3 -m unittest tests/test_generate_dashboard_helm_manifests.py
python3 tests/test_dashboard_helm_chart.py
./tests/helm_kustomize_compare_all.sh kubeflow-dashboard
./tests/helm_kustomize_compare_all.sh
helm lint applications/dashboard/helm --namespace kubeflow
KUBEFLOW_SYNCHRONIZE_NO_COMMIT=true ./scripts/synchronize-dashboard-manifests.sh
git status --porcelain    # empty, regeneration is idempotent
git diff --check

Helm 4.2.2 in the workflows, verified locally against Helm 4.1.0 and
Kustomize v5.8.1.

Contributor Checklist

• I have tested these changes with kustomize. See Installation Prerequisites.
• All commits are signed-off to satisfy the DCO check.
• I have considered adding my company to the adopters page to support Kubeflow and help the community, since I expect help from the community for my issue (see 1. and 2.).

[github-actions]

Welcome to the Kubeflow Community Distribution Repository

Thanks for opening your first PR. Your contribution means a lot to the Kubeflow community.

Before making more PRs:
Please ensure your PR follows our Contributing Guide.
Please also be aware that many components are synchronized from upstream via the scripts in /scripts.
So in some cases you have to fix the problem in the upstream repositories first, but you can use a PR against kubeflow/community-distribution to test the platform integration.

Community Resources:

• CNCF Slack channels: https://www.kubeflow.org/docs/about/community/#kubeflow-slack-channels
• Community meetings: https://www.kubeflow.org/docs/about/community/

Thanks again for helping to improve Kubeflow.

[Copilot]

Pull request overview

Adds a co-located Helm wrapper chart for the Kubeflow Dashboard application and wires it into the existing Helm↔Kustomize render-parity validation and synchronization flow.

Changes:

• Introduce applications/dashboard/helm as a static, scenario-gated Helm wrapper chart rendering the current Dashboard overlays/istio (“platform”) install.
• Extend Helm/Kustomize comparison scripts to include the new kubeflow-dashboard component and scenario.
• Update the Dashboard synchronization script to also refresh the Helm chart appVersion and regenerated static platform.yaml template; update the comparison workflow to install Helm 4.

Reviewed changes

Copilot reviewed 10 out of 11 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
tests/helm_kustomize_compare.sh	Adds kubeflow-dashboard component wiring for parity comparison.
tests/helm_kustomize_compare.py	Allows kubeflow-dashboard as a supported component in the comparison tool.
tests/helm_kustomize_compare_all.sh	Adds kubeflow-dashboard to the “all” comparison matrix.
scripts/synchronize-dashboard-manifests.sh	Extends upstream sync automation to also refresh Helm chart metadata and static template output.
applications/dashboard/helm/values.yaml	Defines default chart values (scenario selection).
applications/dashboard/helm/templates/validate.yaml	Adds scenario validation to fail fast on unsupported values.
applications/dashboard/helm/templates/platform.yaml	Provides the static Kustomize-parity rendered payload for the “platform” scenario.
applications/dashboard/helm/README.md	Documents install shape, caveats, and parity validation commands.
applications/dashboard/helm/ci/values-platform.yaml	CI fixture values for the “platform” scenario.
applications/dashboard/helm/Chart.yaml	Introduces the Dashboard wrapper chart metadata.
.github/workflows/helm-kustomize-comparison.yml	Triggers parity CI for Dashboard changes and installs Helm v4.2.2 via setup action.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 11 changed files in this pull request and generated 1 comment.

[juliusvonkohout]

You are missing the synchronization script changes

[Copilot]

Pull request overview

Copilot reviewed 10 out of 11 changed files in this pull request and generated 3 comments.

[danish9039]

The synchronization script now updates Chart.yaml and regenerates templates/platform.yaml through the shared atomic helper.

[danish9039]

@juliusvonkohout ready for another look.

On maintenance. The generated payloads are output, not source. Three mechanisms keep that honest, now written up in the chart README under How this chart is kept up to date: regeneration is idempotent and CI fails if the tree moves; parity compares the committed chart against a fresh kustomize build, so upstream drift turns the build red; and the seven hand-written resources are declared in the generator, which refuses to run if one stops being rendered by Kustomize rather than dropping it silently. At release n + 10 the payloads are whatever kustomize build produced then.

On configurability. The full table is in the README. Every value maps to something the Kustomize baseline already declares, and every default equals what the overlay renders.

On the login flow. That one is not this chart — it belongs to dex and oauth2-proxy; this chart only reads the identity header they set. You were right that it was not configurable: the Dex chart hardcoded the shape of config.yaml and exposed no way to add a connector, so replacing the demo login meant rewriting the ConfigMap by hand. #3568 fixes that — config.connectors plus extraEnvironmentSecrets, so pointing Dex at Keycloak or LDAP is a values change and credentials stay in a Secret.

Also since the last review: the five-payload classifier is gone, the routing test you flagged as a duplication is removed, and the description has been rewritten because it still described the old design.

One thing I found but did not change here, since it is out of scope for this pull request: parity runs twice per CI run for this component, once inside validate_dashboard_helm_chart in the synchronization script and once in the dedicated comparison job. Happy to remove the in-script run if you want it.

[Copilot]

Pull request overview

Copilot reviewed 31 out of 32 changed files in this pull request and generated no new comments.

Suppressed comments (1)

scripts/helm_manifest_generator.py:293

• Files created by write_text retain the process umask. With a restrictive umask such as 077, each generated payload has mode 0600; the later permission adjustment covers directories only, so another user or container still cannot package the chart despite this function's stated guarantee. Set an explicit readable mode on every generated file after writing it.

            destination.write_text(contents, encoding="utf-8", newline="\n")

[juliusvonkohout]

/lgtm
/approve

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: juliusvonkohout

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [juliusvonkohout]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment