Skip to content

test: add the Helm end-to-end integration workflow - #3595

Open
danish9039 wants to merge 3 commits into
kubeflow:masterfrom
danish9039:gsoc/helm-integration-test
Open

test: add the Helm end-to-end integration workflow#3595
danish9039 wants to merge 3 commits into
kubeflow:masterfrom
danish9039:gsoc/helm-integration-test

Conversation

@danish9039

Copy link
Copy Markdown
Member

What this does

Implements the mentor's direction for Helm integration testing: reuse the existing end-to-end workflow and replace the Kustomize install steps with Helm installs where charts exist. helm_kubeflow_integration_test.yaml is a clone of full_kubeflow_integration_test.yaml with only the install steps changed — the entire test suite (dex_login_test.py, the V1 and V2 pipeline runs, the unauthorized-token check, Katib, KServe, Spark, notebook execution, restricted Pod Security Standards) runs unchanged. The comparison harness already proves the rendered manifests are equivalent; this workflow proves the install path.

Install steps swapped to Helm

step script chart values
Kubeflow Namespaces tests/kubeflow_namespace_helm_install.sh common/kubeflow-namespace/helm ci/values-default.yaml
Multi-Tenancy tests/multi_tenancy_helm_install.sh common/kubeflow-roles/helm ci/values-default.yaml
Certificate Manager tests/cert_manager_helm_install.sh common/cert-manager/helm ci/values-base.yaml then ci/values-kubeflow.yaml, mirroring the base-then-overlay order
Dex tests/dex_helm_install.sh common/dex/helm ci/values-oauth2-proxy.yaml
OAuth2 Proxy tests/oauth2-proxy_helm_install.sh common/oauth2-proxy/helm ci/values-m2m-dex-and-kind.yaml
Dashboard tests/dashboard_helm_install.sh applications/dashboard/helm ci/values-platform.yaml
Notebooks v1 tests/notebooks_helm_install.sh applications/notebooks-v1/helm ci/values-platform.yaml
Katib tests/katib_helm_install.sh experimental/helm/charts/katib ci/values-kubeflow.yaml

Every install uses the ci values file of that chart's comparison scenario, so the installed manifests are exactly the ones tests/run_helm_kustomize_comparison.py proves equivalent to the Kustomize target the original step applied — including the parity fixture credentials the login test depends on. Istio stays on istio-cni_install.sh because the chart's compared scenarios cover the sidecar profile, not the CNI profile the gate installs; that swap needs its own decision.

Growth model

A component's Helm install step joins this workflow in the pull request that adds its chart — the same ownership model as ci/comparison.yaml. The Pipelines chart (#3552, which already carries tests/pipelines_helm_install.sh) and the Spark Operator chart (#3575) each add their one-step swap once this merges. When this workflow has run stably alongside the Kustomize gate, replacing full_kubeflow_integration_test.yaml in place is a small, separately approved follow-up.

Triggers

workflow_dispatch, plus pull_request filtered to chart paths, the Helm install scripts, and this workflow file — so the second full-platform job does not load every pull request while it is being proven.

Verification

  • Every helm template <release> <chart> --namespace <n> --values <ci values> renders under Helm 4.2.2 (nine commands, including both cert-manager phases).
  • bash -n on all eight scripts; workflow parses.
  • The real test is this pull request's own run of the new workflow.

A clone of full_kubeflow_integration_test.yaml that installs every
component with a merged chart through helm install and keeps the
identical test suite. Each install lives in tests/<component>_helm_install.sh,
mirroring the Kustomize script it replaces, and uses the ci values file of
the chart's comparison scenario, so the installed manifests are exactly
the ones the comparison harness proves equivalent. Components without a
chart keep their Kustomize scripts; a chart pull request adds its own
install swap, the same ownership model as ci/comparison.yaml.

Signed-off-by: danish9039 <danishsiddiqui040@gmail.com>
@google-oss-prow

Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign juliusvonkohout for approval. For more information see the Kubernetes Code Review Process.

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

Details Needs approval from an approver in each of these files:

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

@danish9039

Copy link
Copy Markdown
Member Author

/retest

1 similar comment
@danish9039

Copy link
Copy Markdown
Member Author

/retest

Signed-off-by: danish9039 <danishsiddiqui040@gmail.com>
In one revision Helm pre-creates the namespaces its NetworkPolicies
reference, and on a fast runner that bare namespace wins the race against
the chart's labeled Namespace manifest. kubeflow-system then lacks
istio-injection, the trainer pod starts without a sidecar and without the
service.istio.io/canonical-name label, and the trainer-webhook
NetworkPolicy no longer admits the API server's webhook calls. Install
the Namespace objects first, add the policies by upgrade, and assert the
labels landed.

Signed-off-by: danish9039 <danishsiddiqui040@gmail.com>
@danish9039
danish9039 marked this pull request as ready for review September 1, 2026 16:48
@danish9039

Copy link
Copy Markdown
Member Author

@juliusvonkohout for review

@juliusvonkohout

juliusvonkohout commented Sep 2, 2026

Copy link
Copy Markdown
Member

To install is the verb, while the installation is the noun please keep this in mind and do not confuse the two in your text.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

The workflow must run on pushes to master; the noted shell quoting and namespace-install rationale should also be addressed.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Adds a Helm-based end-to-end integration workflow while retaining the existing platform test suite and Kustomize installs where Helm coverage is unavailable.

Changes:

  • Adds Helm installation scripts for eight components.
  • Adds a path-filtered Helm integration workflow.
  • Reuses the existing end-to-end verification suite.
File summaries
File Description
tests/oauth2-proxy_helm_install.sh Installs OAuth2 Proxy through Helm.
tests/notebooks_helm_install.sh Installs Notebooks through Helm.
tests/multi_tenancy_helm_install.sh Installs multi-tenancy roles through Helm.
tests/kubeflow_namespace_helm_install.sh Installs Kubeflow namespaces and network policies.
tests/katib_helm_install.sh Installs Katib through Helm.
tests/dex_helm_install.sh Installs Dex through Helm.
tests/dashboard_helm_install.sh Installs the Dashboard through Helm.
tests/cert_manager_helm_install.sh Installs Certificate Manager through Helm.
.github/workflows/helm_kubeflow_integration_test.yaml Defines the Helm integration workflow.
Review details

Suppressed comments (3)

.github/workflows/helm_kubeflow_integration_test.yaml:14

  • These wildcards also launch this resource-intensive workflow for charts that it does not install, including common/istio/helm and the Hub and KServe UI charts under experimental/helm/charts. A successful run therefore cannot validate those changed installation paths. Restrict the filters to the eight charts currently installed here, and let each future chart add its path together with its Helm installation step.
    - common/*/helm/**
    - applications/*/helm/**
    - applications/*/*/helm/**
    - experimental/helm/charts/**

tests/katib_helm_install.sh:12

  • Quote this environment variable. The repository applies ShellCheck to changed test shell scripts, and this expansion triggers SC2086. Quoting also keeps the command argument stable.
kubectl label namespace $KF_PROFILE katib.kubeflow.org/metrics-collector-injection=enabled --overwrite

tests/kubeflow_namespace_helm_install.sh:11

  • The stated race cannot be caused by this command: it does not pass --create-namespace, Helm does not create namespaces merely because namespaced resources reference them, and Helm 4.2.2 orders Namespace before NetworkPolicy during installation. This explanation therefore does not justify the additional installation revision and can hide the actual failure mechanism. Prefer one installation with the network policies enabled, or document a reproducible Helm defect that requires the two-phase workaround.
# Two phases: the first release revision renders only the Namespace objects,
# the second adds the NetworkPolicies. In one revision Helm pre-creates the
# namespaces its NetworkPolicies reference, and on a fast runner that bare
# namespace wins the race against the chart's own labeled Namespace manifest,
# leaving kubeflow-system without istio-injection and Pod Security labels.
  • Files reviewed: 9/9 changed files
  • Comments generated: 1
  • Review effort level: Balanced

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread .github/workflows/helm_kubeflow_integration_test.yaml
@juliusvonkohout

Copy link
Copy Markdown
Member

Please also add the remaining components such as pipelines

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants