Fix external registry config and other helm tweaks #2212
Conversation
|
WalkthroughThis update introduces several structural and documentation changes to the Kubernetes Helm chart and related configuration for the "trigger" application. The Helm chart version is incremented, and configuration keys are reorganized to scope settings under component-specific sections, particularly for the webapp and registry. Ingress configuration is modularized, with separate blocks for webapp and registry, and new registry ingress resources and helpers are added. Environment variable sourcing in deployment manifests is updated accordingly. Documentation and example YAML files are revised to reflect these changes, and a new "Next steps" section is added to the self-hosting overview documentation. No changes are made to public code entities. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (7)
hosting/k8s/helm/Chart.yaml (1)
5-5: SyncappVersionor document the intentional mismatch
versionis bumped to4.0.0-beta.11whileappVersionremainstrigger-helm-rc.1.
If this is deliberate (e.g., app image tag is not cut for every chart bump), add a short comment in the chart metadata or release notes; otherwise, updateappVersionto avoid confusion for tools that surface both values (Argo-CD, Flux, etc.).hosting/k8s/helm/templates/validate-external-config.yaml (1)
35-38: Remove superfluousorfor clarity
orwith a single operand is redundant:-{{- if or (not .Values.registry.external.host) }} +{{- if not .Values.registry.external.host }}This avoids cognitive overhead while preserving behaviour.
hosting/k8s/helm/templates/NOTES.txt (1)
27-33: Potential false-positive on TLS detection
{{ if $.Values.webapp.ingress.tls }}treats any non-nil list as truthy—even an empty list.
If users leave the key present but empty, the URL will be printed withhttps://, leading to wrong guidance.-http{{ if $.Values.webapp.ingress.tls }}s{{ end }}:// +http{{ if gt (len $.Values.webapp.ingress.tls) 0 }}s{{ end }}://hosting/k8s/helm/templates/registry-ingress.yaml (1)
1-52: Well-structured registry ingress template.The template correctly mirrors the webapp ingress structure while using registry-specific configuration paths. The conditional logic properly ensures the ingress is only created when both the registry is deployed and ingress is enabled.
Add a newline at the end of the file for consistency with standard practices:
{{- end }} +hosting/k8s/helm/values.yaml (3)
522-530: Internal registry defaults may mis-lead non-deploy usersBecause
registry.deploydefaults tofalse, thehost: "registry.example.com"andrepositoryNamespace: "trigger"values are unused in most cases but still appear invalues.yaml.
To avoid confusion you could wrap them in a comment block or move them under adeploy:sub-map so they’re only visible when relevant.
542-549: Two independentauth.*blocks can confuse usersThere is an
authblock for the internal registry and another nested underexternal.
A user switching between the two modes must remember to toggle both, which is easy to miss.Consider:
-registry: - auth: # <- only used when deploy=true +registry: + internalAuth: # explicit scopeor document very explicitly which one is honoured in which mode.
621-648: Missing Docker-registry-specific ingress annotationsMost ingress controllers require extra annotations for the v2 registry API (e.g.
nginx.ingress.kubernetes.io/proxy-body-size,traefik.ingress.kubernetes.io/router.entrypoints, etc.).
Without them large layer uploads can fail with 413s/504s.Add an example block or at least a comment hint so users don’t need to hunt this down later.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (11)
docs/self-hosting/overview.mdx(1 hunks)hosting/k8s/helm/Chart.yaml(1 hunks)hosting/k8s/helm/README.md(4 hunks)hosting/k8s/helm/templates/NOTES.txt(2 hunks)hosting/k8s/helm/templates/_helpers.tpl(2 hunks)hosting/k8s/helm/templates/registry-ingress.yaml(1 hunks)hosting/k8s/helm/templates/validate-external-config.yaml(1 hunks)hosting/k8s/helm/templates/webapp-ingress.yaml(2 hunks)hosting/k8s/helm/templates/webapp.yaml(2 hunks)hosting/k8s/helm/values-production-example.yaml(2 hunks)hosting/k8s/helm/values.yaml(4 hunks)
🧰 Additional context used
🧠 Learnings (11)
📓 Common learnings
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/values.yaml:22-51
Timestamp: 2025-06-25T13:20:17.174Z
Learning: In the Trigger.dev Helm chart values.yaml, the maintainer prefers to use explicit comprehensive warnings for security-sensitive default values rather than implementing secure-by-default behavior that would fail installation. The project uses deterministic default secrets with clear "TESTING ONLY" warnings and instructions for production deployment.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/values-production-example.yaml:95-102
Timestamp: 2025-06-25T14:14:11.965Z
Learning: In the Trigger.dev Helm chart production examples, the maintainer prefers to include initial/bootstrap credentials with clear warnings that they should be changed after first login, rather than requiring external secret references that could complicate initial setup. This follows their pattern of providing working examples with explicit security guidance.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/Chart.yaml:1-18
Timestamp: 2025-06-25T13:18:44.103Z
Learning: For the Trigger.dev Helm chart, the chart name should be "trigger" (not "trigger-v4") since this is the first official chart release. Helper templates should use the actual chart name from .Chart.Name rather than hardcoded prefixes.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/templates/extra-manifests.yaml:1-4
Timestamp: 2025-06-25T13:18:04.827Z
Learning: In the Trigger.dev v4 Helm chart, the user prefers to rely on documentation and examples in values files rather than implementing defensive coding in templates, particularly for features like extraManifests where proper usage is documented.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: .github/workflows/release-helm.yml:42-46
Timestamp: 2025-06-25T13:24:23.836Z
Learning: In .github/workflows/release-helm.yml, the user nicktrn confirmed that using 'entrypoint' with 'docker://' steps works fine, contrary to previous analysis suggesting it's unsupported.
hosting/k8s/helm/Chart.yaml (5)
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/Chart.yaml:1-18
Timestamp: 2025-06-25T13:18:44.103Z
Learning: For the Trigger.dev Helm chart, the chart name should be "trigger" (not "trigger-v4") since this is the first official chart release. Helper templates should use the actual chart name from .Chart.Name rather than hardcoded prefixes.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/values.yaml:22-51
Timestamp: 2025-06-25T13:20:17.174Z
Learning: In the Trigger.dev Helm chart values.yaml, the maintainer prefers to use explicit comprehensive warnings for security-sensitive default values rather than implementing secure-by-default behavior that would fail installation. The project uses deterministic default secrets with clear "TESTING ONLY" warnings and instructions for production deployment.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/templates/extra-manifests.yaml:1-4
Timestamp: 2025-06-25T13:18:04.827Z
Learning: In the Trigger.dev v4 Helm chart, the user prefers to rely on documentation and examples in values files rather than implementing defensive coding in templates, particularly for features like extraManifests where proper usage is documented.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/values-production-example.yaml:95-102
Timestamp: 2025-06-25T14:14:11.965Z
Learning: In the Trigger.dev Helm chart production examples, the maintainer prefers to include initial/bootstrap credentials with clear warnings that they should be changed after first login, rather than requiring external secret references that could complicate initial setup. This follows their pattern of providing working examples with explicit security guidance.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2155
File: docs/docs.json:179-183
Timestamp: 2025-06-06T16:54:23.316Z
Learning: In the docs.json configuration for the Trigger.dev documentation (Mintlify system), both "tags": ["v4"] and "tag": "v4" properties can be used together and work correctly, even though this behavior is undocumented and may not work in local development environments.
docs/self-hosting/overview.mdx (1)
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/values.yaml:22-51
Timestamp: 2025-06-25T13:20:17.174Z
Learning: In the Trigger.dev Helm chart values.yaml, the maintainer prefers to use explicit comprehensive warnings for security-sensitive default values rather than implementing secure-by-default behavior that would fail installation. The project uses deterministic default secrets with clear "TESTING ONLY" warnings and instructions for production deployment.
hosting/k8s/helm/templates/NOTES.txt (4)
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/values.yaml:22-51
Timestamp: 2025-06-25T13:20:17.174Z
Learning: In the Trigger.dev Helm chart values.yaml, the maintainer prefers to use explicit comprehensive warnings for security-sensitive default values rather than implementing secure-by-default behavior that would fail installation. The project uses deterministic default secrets with clear "TESTING ONLY" warnings and instructions for production deployment.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/templates/extra-manifests.yaml:1-4
Timestamp: 2025-06-25T13:18:04.827Z
Learning: In the Trigger.dev v4 Helm chart, the user prefers to rely on documentation and examples in values files rather than implementing defensive coding in templates, particularly for features like extraManifests where proper usage is documented.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/values-production-example.yaml:95-102
Timestamp: 2025-06-25T14:14:11.965Z
Learning: In the Trigger.dev Helm chart production examples, the maintainer prefers to include initial/bootstrap credentials with clear warnings that they should be changed after first login, rather than requiring external secret references that could complicate initial setup. This follows their pattern of providing working examples with explicit security guidance.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/Chart.yaml:1-18
Timestamp: 2025-06-25T13:18:44.103Z
Learning: For the Trigger.dev Helm chart, the chart name should be "trigger" (not "trigger-v4") since this is the first official chart release. Helper templates should use the actual chart name from .Chart.Name rather than hardcoded prefixes.
hosting/k8s/helm/values-production-example.yaml (6)
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/values.yaml:22-51
Timestamp: 2025-06-25T13:20:17.174Z
Learning: In the Trigger.dev Helm chart values.yaml, the maintainer prefers to use explicit comprehensive warnings for security-sensitive default values rather than implementing secure-by-default behavior that would fail installation. The project uses deterministic default secrets with clear "TESTING ONLY" warnings and instructions for production deployment.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/values-production-example.yaml:95-102
Timestamp: 2025-06-25T14:14:11.965Z
Learning: In the Trigger.dev Helm chart production examples, the maintainer prefers to include initial/bootstrap credentials with clear warnings that they should be changed after first login, rather than requiring external secret references that could complicate initial setup. This follows their pattern of providing working examples with explicit security guidance.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/templates/extra-manifests.yaml:1-4
Timestamp: 2025-06-25T13:18:04.827Z
Learning: In the Trigger.dev v4 Helm chart, the user prefers to rely on documentation and examples in values files rather than implementing defensive coding in templates, particularly for features like extraManifests where proper usage is documented.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: The 'trigger.config.ts' file configures the Trigger.dev project, specifying task directories, retry settings, telemetry, runtime, machine settings, log level, max duration, and build extensions.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2155
File: hosting/docker/.env.example:4-7
Timestamp: 2025-06-06T23:55:01.933Z
Learning: In the trigger.dev project, .env.example files should contain actual example secret values rather than placeholders, as these help users understand the expected format. The files include clear warnings about not using these defaults in production and instructions for generating proper secrets.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2155
File: hosting/docker/registry/auth.htpasswd:1-1
Timestamp: 2025-06-06T18:49:18.144Z
Learning: Example credentials in self-hosting documentation files are acceptable when they serve as templates or examples for users to understand the setup process, particularly in hosting/docker configuration files.
hosting/k8s/helm/README.md (5)
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/values.yaml:22-51
Timestamp: 2025-06-25T13:20:17.174Z
Learning: In the Trigger.dev Helm chart values.yaml, the maintainer prefers to use explicit comprehensive warnings for security-sensitive default values rather than implementing secure-by-default behavior that would fail installation. The project uses deterministic default secrets with clear "TESTING ONLY" warnings and instructions for production deployment.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/values-production-example.yaml:95-102
Timestamp: 2025-06-25T14:14:11.965Z
Learning: In the Trigger.dev Helm chart production examples, the maintainer prefers to include initial/bootstrap credentials with clear warnings that they should be changed after first login, rather than requiring external secret references that could complicate initial setup. This follows their pattern of providing working examples with explicit security guidance.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/templates/extra-manifests.yaml:1-4
Timestamp: 2025-06-25T13:18:04.827Z
Learning: In the Trigger.dev v4 Helm chart, the user prefers to rely on documentation and examples in values files rather than implementing defensive coding in templates, particularly for features like extraManifests where proper usage is documented.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/Chart.yaml:1-18
Timestamp: 2025-06-25T13:18:44.103Z
Learning: For the Trigger.dev Helm chart, the chart name should be "trigger" (not "trigger-v4") since this is the first official chart release. Helper templates should use the actual chart name from .Chart.Name rather than hardcoded prefixes.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: The 'trigger.config.ts' file configures the Trigger.dev project, specifying task directories, retry settings, telemetry, runtime, machine settings, log level, max duration, and build extensions.
hosting/k8s/helm/templates/webapp-ingress.yaml (3)
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/values.yaml:22-51
Timestamp: 2025-06-25T13:20:17.174Z
Learning: In the Trigger.dev Helm chart values.yaml, the maintainer prefers to use explicit comprehensive warnings for security-sensitive default values rather than implementing secure-by-default behavior that would fail installation. The project uses deterministic default secrets with clear "TESTING ONLY" warnings and instructions for production deployment.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/Chart.yaml:1-18
Timestamp: 2025-06-25T13:18:44.103Z
Learning: For the Trigger.dev Helm chart, the chart name should be "trigger" (not "trigger-v4") since this is the first official chart release. Helper templates should use the actual chart name from .Chart.Name rather than hardcoded prefixes.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/templates/extra-manifests.yaml:1-4
Timestamp: 2025-06-25T13:18:04.827Z
Learning: In the Trigger.dev v4 Helm chart, the user prefers to rely on documentation and examples in values files rather than implementing defensive coding in templates, particularly for features like extraManifests where proper usage is documented.
hosting/k8s/helm/templates/webapp.yaml (1)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-06-24T08:06:34.164Z
Learning: In the Remix 2.1.0 webapp (apps/webapp), all environment variables must be accessed via the 'env' export from env.server.ts, never directly from process.env, to ensure consistent and secure environment management.
hosting/k8s/helm/templates/registry-ingress.yaml (1)
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/templates/extra-manifests.yaml:1-4
Timestamp: 2025-06-25T13:18:04.827Z
Learning: In the Trigger.dev v4 Helm chart, the user prefers to rely on documentation and examples in values files rather than implementing defensive coding in templates, particularly for features like extraManifests where proper usage is documented.
hosting/k8s/helm/templates/_helpers.tpl (3)
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/Chart.yaml:1-18
Timestamp: 2025-06-25T13:18:44.103Z
Learning: For the Trigger.dev Helm chart, the chart name should be "trigger" (not "trigger-v4") since this is the first official chart release. Helper templates should use the actual chart name from .Chart.Name rather than hardcoded prefixes.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/templates/extra-manifests.yaml:1-4
Timestamp: 2025-06-25T13:18:04.827Z
Learning: In the Trigger.dev v4 Helm chart, the user prefers to rely on documentation and examples in values files rather than implementing defensive coding in templates, particularly for features like extraManifests where proper usage is documented.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/values.yaml:22-51
Timestamp: 2025-06-25T13:20:17.174Z
Learning: In the Trigger.dev Helm chart values.yaml, the maintainer prefers to use explicit comprehensive warnings for security-sensitive default values rather than implementing secure-by-default behavior that would fail installation. The project uses deterministic default secrets with clear "TESTING ONLY" warnings and instructions for production deployment.
hosting/k8s/helm/values.yaml (7)
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/values.yaml:22-51
Timestamp: 2025-06-25T13:20:17.174Z
Learning: In the Trigger.dev Helm chart values.yaml, the maintainer prefers to use explicit comprehensive warnings for security-sensitive default values rather than implementing secure-by-default behavior that would fail installation. The project uses deterministic default secrets with clear "TESTING ONLY" warnings and instructions for production deployment.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/values-production-example.yaml:95-102
Timestamp: 2025-06-25T14:14:11.965Z
Learning: In the Trigger.dev Helm chart production examples, the maintainer prefers to include initial/bootstrap credentials with clear warnings that they should be changed after first login, rather than requiring external secret references that could complicate initial setup. This follows their pattern of providing working examples with explicit security guidance.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2155
File: hosting/docker/.env.example:4-7
Timestamp: 2025-06-06T23:55:01.933Z
Learning: In the trigger.dev project, .env.example files should contain actual example secret values rather than placeholders, as these help users understand the expected format. The files include clear warnings about not using these defaults in production and instructions for generating proper secrets.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: The 'trigger.config.ts' file configures the Trigger.dev project, specifying task directories, retry settings, telemetry, runtime, machine settings, log level, max duration, and build extensions.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/templates/extra-manifests.yaml:1-4
Timestamp: 2025-06-25T13:18:04.827Z
Learning: In the Trigger.dev v4 Helm chart, the user prefers to rely on documentation and examples in values files rather than implementing defensive coding in templates, particularly for features like extraManifests where proper usage is documented.
Learnt from: zvictor
PR: triggerdotdev/trigger.dev#1686
File: packages/build/src/extensions/python.ts:110-116
Timestamp: 2025-02-10T10:56:31.402Z
Learning: In Docker build contexts for Trigger.dev extensions, avoid over-engineering security measures when handling user-provided configuration (like Python requirements) as the build context is already isolated and the content is user-controlled.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2150
File: apps/supervisor/src/workloadManager/docker.ts:115-115
Timestamp: 2025-06-04T16:02:22.957Z
Learning: In the Trigger.dev codebase, the supervisor component uses DOCKER_ENFORCE_MACHINE_PRESETS while the docker provider component uses ENFORCE_MACHINE_PRESETS. These are separate components with separate environment variable configurations for the same logical concept of enforcing machine presets.
🪛 YAMLlint (1.37.1)
hosting/k8s/helm/templates/webapp-ingress.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 15-15: wrong indentation: expected 0 but found 2
(indentation)
hosting/k8s/helm/templates/registry-ingress.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 15-15: wrong indentation: expected 0 but found 2
(indentation)
[error] 52-52: no new line character at the end of file
(new-line-at-end-of-file)
⏰ Context from checks skipped due to timeout of 90000ms (25)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (4, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 10)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 10)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (10, 10)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (9, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (8, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (7, 10)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (8, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - pnpm)
- GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - npm)
- GitHub Check: typecheck / typecheck
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (15)
docs/self-hosting/overview.mdx (1)
98-107: Double-check links and icon availability
- Verify that
/self-hosting/dockerand/self-hosting/kubernetesroutes actually resolve in the docs build; otherwise the cards will render dead links.- Ensure the
dharmachakraicon is included in the Mintlify icon set—if it isn’t, the build will fail (Mintlify throws on unknown icons).If either resource is missing, swap the icon or adjust the path before merging.
hosting/k8s/helm/templates/NOTES.txt (1)
89-91: Confirm SprighasPrefixargument order
hasPrefixexpects(prefix, string). Current usage looks correct:{{- if hasPrefix "localhost" .Values.registry.external.host }}Just flagging for a quick re-check since reversing the order silently returns
false.hosting/k8s/helm/values-production-example.yaml (2)
15-38: YAML indentation & key names look good—no actionThe new
webapp.ingressblock is well-formed and aligns with the updated templates. 👍
114-130: Nice addition of a dedicated registry ingress exampleExample values are consistent with the template expectations and include TLS hints—nothing to change.
hosting/k8s/helm/templates/webapp-ingress.yaml (1)
1-52: Configuration restructuring looks good!The migration from
.Values.ingressto.Values.webapp.ingressis consistent throughout the template, and the webapp-specific naming and labeling aligns well with the modular approach. The helper template reference update totrigger-v4.webapp.ingress.annotationsproperly matches the new structure.Note: The static analysis YAML syntax warnings are false positives - the
{{-Helm template syntax is valid and the indentation is correctly handled by the template engine.hosting/k8s/helm/templates/webapp.yaml (2)
174-179: Environment variable sourcing updated correctly.The migration from
.Values.configto.Values.webappfor the origin URLs is consistent with the overall configuration restructuring and improves modularity.
196-198: OTEL endpoint configuration updated appropriately.Using
.Values.webapp.appOriginfor the OTEL exporter endpoint maintains consistency with the webapp-scoped configuration approach.hosting/k8s/helm/README.md (3)
115-126: Documentation structure updated correctly.The configuration examples now properly reflect the webapp-scoped structure for application URLs and bootstrap settings, aligning with the template changes.
133-159: External services configuration simplified appropriately.The change from separate
enabledandexternalflags to a singledeployboolean makes the configuration more intuitive and easier to understand.
163-197: Ingress configuration separation documented well.The split between
webapp.ingressandregistry.ingressconfigurations is clearly documented with appropriate examples for both components, making it easy for users to configure each ingress independently.hosting/k8s/helm/templates/_helpers.tpl (3)
239-245: Registry host helper simplified appropriately.Removing the port suffix from the registry host helper aligns with the configuration simplification and matches the external registry configuration changes.
309-324: Webapp ingress annotations helper updated correctly.The helper has been properly renamed and scoped to use
.Values.webapp.ingressconfiguration, maintaining the same annotation merging logic while supporting the modular structure.
326-342: Registry ingress annotations helper implemented consistently.The new registry helper follows the same pattern as the webapp helper, ensuring consistent annotation handling across both ingress components.
hosting/k8s/helm/values.yaml (2)
53-57: Breaking change: add an upgrade-path (or alias) for moved origin keys
appOrigin,loginOrigin, andapiOriginhave been relocated from the formerconfigblock towebapp.*. Any existing automation (Helmfile, GitOps, Argo CD, CI templates, etc.) that still sets.Values.config.*will silently break.Consider one of the following:
+# Temporary backward-compat until the next major bump +config: + appOrigin: {{ .Values.webapp.appOrigin }} + loginOrigin: {{ .Values.webapp.loginOrigin }} + apiOrigin: {{ .Values.webapp.apiOrigin }}or emit a clear
fail/warninNOTES.txttelling users to move the keys.
This keeps upgrades predictable without blocking the re-org.
172-199: Default ingress host and default origins disagree
webapp.ingress.hosts[0].hostdefaults totrigger.local, while the three origin URLs above still point atlocalhost:3040.
If a user simply flipswebapp.ingress.enabled=true, OIDC redirects and cookie domains will not match and the UI will break.Recommend either:
- Derive a single default from
appOrigin({{ .Values.webapp.appOrigin | urlParse "host" }}) or- Add a NOTE in the chart README/NOTES.txt reminding users to keep the two in sync.
This PR ensures a more robust and user-friendly experience for self-hosting Trigger.dev with proper registry configuration validation and clearer guidance.
Changes Made
🔧 Registry Configuration Fixes
webapp-ingress.yamlandregistry-ingress.yaml) for better organization and independent configurationvalidate-external-config.yamlto ensure external registry configuration is provided whenregistry.deploy=falseNOTES.txtwhen using localhost for the registry, alerting users that this configuration only works for local testing (kind/minikube)📚 Documentation Improvements
docs/self-hosting/overview.mdxwith clear cards directing users to Docker and Kubernetes deployment guides📦 Chart Updates
4.0.0-beta.11