[khuyentran1401]

Why

Teams with an existing Helm chart had no steps on nebari.dev for connecting it to Nebari. This page now shows how using the official nebari-app library chart.

Reference Issues or PRs

See also nebari-dev/software-pack-template#32 (template switches to nebari-app) and nebari-dev/software-pack-template#33 (matching README updates).

What does this implement/fix?

• Suggest which way to build a pack depending on whether the app has a Helm chart or not.
• New "Add the NebariApp to a Helm chart" section.

Testing

• Did you test the pull request locally?
• Did you add new tests?

[github-actions]

Docs preview for docs/update-build-your-own:

• Nebari (via the nebari-docs Worker): https://docs-update-build-your-own-nebari-docs.openteams-account.workers.dev
• Nebari Classic (via the nebari-docs-classic Worker): https://docs-update-build-your-own-nebari-docs-classic.openteams-account.workers.dev

[dcmcand]

Requesting changes. The direction is right, but the values example in step 2 produces a NebariApp that the operator won't route.

The operator only creates an HTTPRoute when spec.routing is set. With no routing block, it deletes any existing routes, sets RoutingReady=False with reason RoutingNotConfigured, and treats TLS as disabled (see nebariapp_controller.go and isTLSEnabled in tls/reconciler.go). Nothing fills in routing for you: there's no defaulting webhook, the CRD has no default for it, and the library chart passes spec through unchanged. The operator's e2e suite applies exactly this shape (hostname and service only) and asserts it ends up RoutingNotConfigured (conditions_test.go). The operator's own guide in docs/using-the-nebari-app-chart.md includes routing, and we should match it:

nebariapp:
  enabled: false
  hostname: '{{ fail "nebariapp.hostname is required when nebariapp.enabled is true" }}'
  service:
    name: '{{ include "my-pack.fullname" . | toJson }}'
    port: '{{ .Values.service.port }}'
  routing:
    routes:
      - pathPrefix: /

TLS is on by default once routing is present, so the basic case needs nothing else.

One other change we should make. The library template uses toYamlPretty, which was added in Helm 3.17.0. We should state that as the minimum Helm version.

[dcmcand]

Thanks, both items are addressed. The values example now includes routing, so the rendered NebariApp gets an HTTPRoute and TLS by default. I confirmed it by rendering a scratch chart against nebari-app 0.1.1 and checking the output against the v0.1.1 controller. The Helm 3.17.0 minimum is stated in step 1. LGTM.