Helm chart improvements #2207
Helm chart improvements #2207
Conversation
|
WalkthroughThis update introduces major refactoring and feature enhancements to the Kubernetes Helm chart and associated documentation for the application. The Helm chart now uses Bitnami upstream charts for PostgreSQL, Redis, ClickHouse, and S3/MinIO as dependencies, removing the in-repo templates for these services. Service deployment toggles and external connection configurations are standardized using ✨ Finishing Touches
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: 1
🔭 Outside diff range comments (2)
hosting/k8s/helm/templates/supervisor.yaml (1)
45-66:supervisoris rendered unconditionally – missingdeploygateEvery other component now uses a
*.deployswitch.
The supervisor Deployment & Service are no longer wrapped in such a guard, so they will be created even whensupervisor.deploy: false, which contradicts the new convention and may break clusters where an external supervisor runs.+{{- if .Values.supervisor.deploy }} apiVersion: apps/v1 kind: Deployment ... {{- include "trigger-v4.componentSelectorLabels" ... }} @@ {{- end }}(Add the terminating
{{- end }}after the Service block.)hosting/k8s/helm/README.md (1)
134-163: External service examples missing deploy flag.The external service configuration examples should include
deploy: falseto clearly indicate how to use external services instead of deployed ones.Apply this pattern to all external service examples:
# External PostgreSQL postgres: - enabled: false - external: true + deploy: false external: host: "your-postgres.rds.amazonaws.com"
🧹 Nitpick comments (7)
apps/webapp/app/hooks/useTriggerCliTag.ts (1)
7-7: Consider defensive coding for the non-null assertion.While the root route loader should always be available in a Remix app, consider adding a fallback to make the code more resilient:
- return routeMatch!.triggerCliTag; + return routeMatch?.triggerCliTag ?? "latest";hosting/k8s/helm/templates/electric.yaml (1)
49-59: Probe parameters should fall back to safe defaultsThe probe blocks assume that, once
*.enabledistrue, all numeric sub-fields are present and valid.
If a user simply flips theenabledflag without copying the whole stanza, Helm will rendernullvalues which will make the Deployment invalid.A compact way to avoid the foot-gun:
- initialDelaySeconds: {{ .Values.electric.livenessProbe.initialDelaySeconds }} + initialDelaySeconds: {{ .Values.electric.livenessProbe.initialDelaySeconds | default 10 }}(repeat for the other five fields in liveness / readiness / startup).
This keeps templates robust while still letting power-users override every knob.
Also applies to: 60-70, 71-81
hosting/k8s/helm/templates/validate-external-config.yaml (1)
5-15: Consider guarding against missingexternalobjectsAccessing e.g.
.Values.redis.external.hostwhen the parent key is not defined works (it yields<no value>), but it’s brittle and makes the template harder to read.A defensive, still concise, alternative:
{{- if (and (not .Values.redis.deploy) (empty (dig "redis" "external" "host" .Values))) }} {{- fail "redis.external.host is required when redis.deploy=false" }} {{- end }}
digavoids dotted lookups onniland reads more declaratively.Also applies to: 23-33, 35-39
hosting/k8s/helm/templates/supervisor.yaml (2)
166-173: Invisible template statements leak indentationThe
{{- ... }}used for the local$registryAuthEnabledassignment strips all preceding spaces.
Because it sits inside theenv:list item, this leaves a blank, zero-indentation line in the rendered YAML, which YAMLLint (and some k8s admission controllers) flag as malformed.- {{- $registryAuthEnabled := false }} + {{/* assign without stripping indentation */}} + {{ $registryAuthEnabled := false }}Do the same for the subsequent
if/elseblocks.
284-284: Missing trailing newlineA trailing newline keeps
git diffoutputs clean and silences linters.hosting/k8s/helm/templates/webapp.yaml (1)
117-117: Environment variables updated correctly.The S3 URL helper change aligns with the MinIO to S3 renaming. The new
TRIGGER_CLI_TAGenvironment variable matches the PR objective.Note: The CLI tag is hardcoded to "v4-beta" - consider making this configurable via values if different tags need to be supported.
Also applies to: 120-121
hosting/k8s/helm/values.yaml (1)
297-328: PostgreSQL configuration properly structured for Bitnami chart.The configuration correctly implements the deploy flag pattern and separates internal Bitnami chart settings from external connection details. The
listen_addresses = '*'is necessary for container networking.Note: Consider documenting that
sslMode: "disable"should be changed to"require"or"verify-full"for production use.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
hosting/k8s/helm/Chart.lockis excluded by!**/*.lock
📒 Files selected for processing (30)
.github/workflows/release-helm.yml(3 hunks)apps/webapp/app/components/SetupCommands.tsx(5 hunks)apps/webapp/app/env.server.ts(1 hunks)apps/webapp/app/hooks/useTriggerCliTag.ts(1 hunks)apps/webapp/app/root.tsx(1 hunks)docs/self-hosting/kubernetes.mdx(7 hunks)hosting/k8s/helm/.gitignore(1 hunks)hosting/k8s/helm/Chart.yaml(2 hunks)hosting/k8s/helm/README.md(8 hunks)hosting/k8s/helm/templates/NOTES.txt(1 hunks)hosting/k8s/helm/templates/_helpers.tpl(3 hunks)hosting/k8s/helm/templates/clickhouse.yaml(0 hunks)hosting/k8s/helm/templates/configmap.yaml(0 hunks)hosting/k8s/helm/templates/electric.yaml(2 hunks)hosting/k8s/helm/templates/minio.yaml(0 hunks)hosting/k8s/helm/templates/postgresql.yaml(0 hunks)hosting/k8s/helm/templates/redis.yaml(0 hunks)hosting/k8s/helm/templates/registry.yaml(4 hunks)hosting/k8s/helm/templates/secrets.yaml(2 hunks)hosting/k8s/helm/templates/supervisor.yaml(4 hunks)hosting/k8s/helm/templates/tests/test-clickhouse.yaml(1 hunks)hosting/k8s/helm/templates/tests/test-electric.yaml(1 hunks)hosting/k8s/helm/templates/tests/test-postgresql.yaml(2 hunks)hosting/k8s/helm/templates/tests/test-redis.yaml(2 hunks)hosting/k8s/helm/templates/tests/test-s3.yaml(1 hunks)hosting/k8s/helm/templates/tests/test-supervisor.yaml(1 hunks)hosting/k8s/helm/templates/validate-external-config.yaml(1 hunks)hosting/k8s/helm/templates/webapp.yaml(3 hunks)hosting/k8s/helm/values-production-example.yaml(4 hunks)hosting/k8s/helm/values.yaml(9 hunks)
💤 Files with no reviewable changes (5)
- hosting/k8s/helm/templates/configmap.yaml
- hosting/k8s/helm/templates/minio.yaml
- hosting/k8s/helm/templates/postgresql.yaml
- hosting/k8s/helm/templates/clickhouse.yaml
- hosting/k8s/helm/templates/redis.yaml
🧰 Additional context used
📓 Path-based instructions (2)
`apps/webapp/**/*`: The webapp at apps/webapp is a Remix 2.1 app that uses Node.js v20. Use zod extensively in the webapp.
apps/webapp/**/*: The webapp at apps/webapp is a Remix 2.1 app that uses Node.js v20.
Use zod extensively in the webapp.
📄 Source: CodeRabbit Inference Engine (.github/copilot-instructions.md)
List of files the instruction was applied to:
apps/webapp/app/root.tsxapps/webapp/app/hooks/useTriggerCliTag.tsapps/webapp/app/components/SetupCommands.tsxapps/webapp/app/env.server.ts
`apps/webapp/app/env.server.ts`: All environment variables in the webapp must be accessed through the 'env' export of env.server.ts, never directly via process.env.
apps/webapp/app/env.server.ts: All environment variables in the webapp must be accessed through the 'env' export of env.server.ts, never directly via process.env.
📄 Source: CodeRabbit Inference Engine (.cursor/rules/webapp.mdc)
List of files the instruction was applied to:
apps/webapp/app/env.server.ts
🧠 Learnings (25)
📓 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/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: .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.
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.
hosting/k8s/helm/templates/tests/test-supervisor.yaml (2)
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.
hosting/k8s/helm/templates/tests/test-electric.yaml (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/.gitignore (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/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: Files with '.test' or '.spec' in their names are automatically excluded from task discovery, but this can be customized with 'ignorePatterns' in 'trigger.config.ts'.
hosting/k8s/helm/templates/tests/test-redis.yaml (2)
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/templates/tests/test-clickhouse.yaml (2)
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.
apps/webapp/app/root.tsx (10)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: When implementing Trigger.dev tasks in files under '**/trigger/**/*.{ts,tsx,js,jsx}', always import from '@trigger.dev/sdk/v3' and export every task, including subtasks, to ensure correct discovery and execution.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: Incorrect implementation of Trigger.dev tasks (wrong imports, missing exports, deprecated patterns) will break production, fail deployment, and fail to run locally.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: Build extensions in 'trigger.config.ts' allow customization of the build process, such as copying files, including packages, installing system dependencies, and enabling TypeScript features.
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: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-06-24T08:06:34.164Z
Learning: Use 'presenters' (located in app/v3/presenters/**/*.server.ts) to encapsulate complex loader logic into classes, improving code organization and testability.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-06-24T08:06:34.164Z
Learning: When importing from @trigger.dev/core in the webapp, always use subpath exports rather than the root package path to ensure modularity and avoid unnecessary dependencies.
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.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: Before generating any Trigger.dev task code, always verify: (1) imports are from '@trigger.dev/sdk/v3', (2) every task is exported, and (3) no deprecated code patterns are present.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-06-24T08:06:34.164Z
Learning: When writing tests in the webapp (apps/webapp/app/**/*.test.{ts,tsx}), avoid importing env.server.ts directly or indirectly; instead, ensure that all dependencies are testable and receive configuration via options, not environment variables.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: For React frontends, use '@trigger.dev/react-hooks' and provide the public access token via context or props; prefer Realtime hooks over SWR hooks for live updates.
apps/webapp/app/hooks/useTriggerCliTag.ts (8)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: For React frontends, use '@trigger.dev/react-hooks' and provide the public access token via context or props; prefer Realtime hooks over SWR hooks for live updates.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: When implementing Trigger.dev tasks in files under '**/trigger/**/*.{ts,tsx,js,jsx}', always import from '@trigger.dev/sdk/v3' and export every task, including subtasks, to ensure correct discovery and execution.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-06-24T08:06:34.164Z
Learning: When importing from @trigger.dev/core in the webapp, always use subpath exports rather than the root package path to ensure modularity and avoid unnecessary dependencies.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: Build extensions in 'trigger.config.ts' allow customization of the build process, such as copying files, including packages, installing system dependencies, and enabling TypeScript features.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: Incorrect implementation of Trigger.dev tasks (wrong imports, missing exports, deprecated patterns) will break production, fail deployment, and fail to run locally.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: Before generating any Trigger.dev task code, always verify: (1) imports are from '@trigger.dev/sdk/v3', (2) every task is exported, and (3) no deprecated code patterns are present.
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 deprecated 'client.defineJob' pattern must never be used in Trigger.dev tasks; always use the 'task' function from '@trigger.dev/sdk/v3' for defining tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: When triggering tasks from backend code, use 'tasks.trigger', 'tasks.batchTrigger', or 'tasks.triggerAndPoll' from '@trigger.dev/sdk/v3', and use type-only imports for type safety.
hosting/k8s/helm/templates/tests/test-s3.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/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.
hosting/k8s/helm/templates/tests/test-postgresql.yaml (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/secrets.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/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.
docs/self-hosting/kubernetes.mdx (6)
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.
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: 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.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2195
File: hosting/k8s/helm/templates/minio.yaml:49-55
Timestamp: 2025-06-25T13:29:54.392Z
Learning: In MinIO deployments, the MINIO_ROOT_USER and MINIO_ROOT_PASSWORD environment variables are only used during the first start/initialization of MinIO. These are bootstrap credentials that should be changed after the initial setup is complete.
apps/webapp/app/components/SetupCommands.tsx (12)
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: When implementing Trigger.dev tasks in files under '**/trigger/**/*.{ts,tsx,js,jsx}', always import from '@trigger.dev/sdk/v3' and export every task, including subtasks, to ensure correct discovery and execution.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: Before generating any Trigger.dev task code, always verify: (1) imports are from '@trigger.dev/sdk/v3', (2) every task is exported, and (3) no deprecated code patterns are present.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: Incorrect implementation of Trigger.dev tasks (wrong imports, missing exports, deprecated patterns) will break production, fail deployment, and fail to run locally.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: Build extensions in 'trigger.config.ts' allow customization of the build process, such as copying files, including packages, installing system dependencies, and enabling TypeScript features.
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: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: The deprecated 'client.defineJob' pattern must never be used in Trigger.dev tasks; always use the 'task' function from '@trigger.dev/sdk/v3' for defining tasks.
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.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-06-24T08:06:34.164Z
Learning: When importing from @trigger.dev/core in the webapp, always use subpath exports rather than the root package path to ensure modularity and avoid unnecessary dependencies.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: When triggering tasks from backend code, use 'tasks.trigger', 'tasks.batchTrigger', or 'tasks.triggerAndPoll' from '@trigger.dev/sdk/v3', and use type-only imports for type safety.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: Each Trigger.dev task must have a unique 'id' property within the project to avoid conflicts and ensure correct identification.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: For React frontends, use '@trigger.dev/react-hooks' and provide the public access token via context or props; prefer Realtime hooks over SWR hooks for live updates.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: Trigger.dev tasks support lifecycle hooks such as 'init', 'cleanup', 'onStart', 'onSuccess', 'onFailure', and 'handleError' for advanced control over task execution and error handling.
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.
hosting/k8s/helm/templates/validate-external-config.yaml (3)
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.
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.
.github/workflows/release-helm.yml (3)
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.
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.
hosting/k8s/helm/templates/supervisor.yaml (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/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#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.
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/templates/registry.yaml (3)
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.
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.
hosting/k8s/helm/values-production-example.yaml (5)
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/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#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#2195
File: hosting/k8s/helm/templates/minio.yaml:49-55
Timestamp: 2025-06-25T13:29:54.392Z
Learning: In MinIO deployments, the MINIO_ROOT_USER and MINIO_ROOT_PASSWORD environment variables are only used during the first start/initialization of MinIO. These are bootstrap credentials that should be changed after the initial setup is complete.
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/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-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: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-06-24T08:06:34.164Z
Learning: The Prisma client (from @trigger.dev/database) is set up in db.server.ts and should be used for all PostgreSQL access in the webapp.
hosting/k8s/helm/templates/NOTES.txt (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/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.
hosting/k8s/helm/templates/webapp.yaml (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/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.
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.
apps/webapp/app/env.server.ts (12)
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.
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: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: When implementing Trigger.dev tasks in files under '**/trigger/**/*.{ts,tsx,js,jsx}', always import from '@trigger.dev/sdk/v3' and export every task, including subtasks, to ensure correct discovery and execution.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: Each Trigger.dev task must have a unique 'id' property within the project to avoid conflicts and ensure correct identification.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: Incorrect implementation of Trigger.dev tasks (wrong imports, missing exports, deprecated patterns) will break production, fail deployment, and fail to run locally.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: Build extensions in 'trigger.config.ts' allow customization of the build process, such as copying files, including packages, installing system dependencies, and enabling TypeScript features.
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.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-06-24T08:06:34.164Z
Learning: When writing tests in the webapp (apps/webapp/app/**/*.test.{ts,tsx}), avoid importing env.server.ts directly or indirectly; instead, ensure that all dependencies are testable and receive configuration via options, not environment variables.
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 deprecated 'client.defineJob' pattern must never be used in Trigger.dev tasks; always use the 'task' function from '@trigger.dev/sdk/v3' for defining tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-06-24T08:07:10.028Z
Learning: Before generating any Trigger.dev task code, always verify: (1) imports are from '@trigger.dev/sdk/v3', (2) every task is exported, and (3) no deprecated code patterns are present.
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#1608
File: apps/webapp/app/v3/services/triggerTask.server.ts:418-418
Timestamp: 2025-01-13T18:31:48.160Z
Learning: The `MachinePresetName` schema is used to validate machine preset values in the trigger.dev codebase, ensuring type safety and validation of machine preset options.
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.
hosting/k8s/helm/templates/_helpers.tpl (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/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/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#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.
hosting/k8s/helm/values.yaml (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/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: 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#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.
🧬 Code Graph Analysis (2)
apps/webapp/app/root.tsx (1)
apps/webapp/app/env.server.ts (1)
env(865-865)
apps/webapp/app/hooks/useTriggerCliTag.ts (1)
apps/webapp/app/root.tsx (1)
loader(41-64)
🪛 YAMLlint (1.37.1)
hosting/k8s/helm/templates/tests/test-supervisor.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
hosting/k8s/helm/templates/tests/test-electric.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
hosting/k8s/helm/templates/tests/test-redis.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
hosting/k8s/helm/templates/tests/test-clickhouse.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
hosting/k8s/helm/templates/tests/test-s3.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
hosting/k8s/helm/templates/tests/test-postgresql.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
hosting/k8s/helm/templates/electric.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
hosting/k8s/helm/templates/validate-external-config.yaml
[error] 2-2: syntax error: expected ',' or '}', but got ':'
(syntax)
[error] 56-56: no new line character at the end of file
(new-line-at-end-of-file)
hosting/k8s/helm/templates/supervisor.yaml
[error] 284-284: no new line character at the end of file
(new-line-at-end-of-file)
hosting/k8s/helm/templates/registry.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
🪛 LanguageTool
hosting/k8s/helm/templates/NOTES.txt
[style] ~64-~64: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...{ .Values.postgres.external.host }}:{{ .Values.postgres.external.port | default 5432 }...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~69-~69: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...t {{ .Values.redis.external.host }}:{{ .Values.redis.external.port | default 6379 }} {...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~79-~79: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ....Values.clickhouse.external.host }}:{{ .Values.clickhouse.external.httpPort | default ...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~89-~89: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...{ .Values.registry.external.host }}:{{ .Values.registry.external.port }} {{- if eq .Va...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
⏰ Context from checks skipped due to timeout of 90000ms (25)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (8, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (4, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 10)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (10, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (7, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (9, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (8, 10)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 10)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 10)
- 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 - pnpm)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - npm)
- GitHub Check: typecheck / typecheck
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (49)
hosting/k8s/helm/.gitignore (1)
3-4: LGTM! Standard Helm dependency management.Adding
*.tgzand/chartsto.gitignoreis correct for Helm charts using Bitnami dependencies. These are generated artifacts that should not be versioned.hosting/k8s/helm/templates/tests/test-supervisor.yaml (1)
1-1: LGTM! Deployment flag standardization is correct.The change from
supervisor.enabledtosupervisor.deployaligns with the unified deployment flag convention described in the PR objectives.Note: The YAMLlint syntax error is a false positive -
{{- ifis valid Helm template syntax.hosting/k8s/helm/templates/tests/test-electric.yaml (1)
1-1: LGTM! Consistent deployment flag standardization.The change from
electric.enabledtoelectric.deployis consistent with the broader Helm chart refactoring for unified deployment flags.hosting/k8s/helm/templates/tests/test-clickhouse.yaml (1)
1-1: LGTM! Simplified conditional logic improves maintainability.The change from checking both
clickhouse.enabledand!clickhouse.externalto justclickhouse.deploysimplifies the logic while maintaining the same behavior under the new unified deployment flag convention.apps/webapp/app/hooks/useTriggerCliTag.ts (1)
1-8: LGTM! Hook implementation supports dynamic CLI versioning correctly.The hook properly uses
useTypedRouteLoaderDatato access thetriggerCliTagfrom the root loader, enabling the dynamic CLI versioning feature described in the PR objectives.apps/webapp/app/env.server.ts (1)
859-861: LGTM! Well-implemented environment variable addition.The new
TRIGGER_CLI_TAGenvironment variable follows the established zod schema pattern with appropriate typing, default value, and descriptive comment. This enables dynamic CLI package tag configuration for setup commands.hosting/k8s/helm/templates/tests/test-redis.yaml (2)
1-1: LGTM! Deployment flag standardization improves consistency.The change from checking separate
enabledandexternalflags to a unifieddeployflag simplifies the conditional logic and aligns with the broader Helm chart refactoring.
14-14: LGTM! Enhanced image specification provides better flexibility.The fully qualified image path using registry, repository, and tag values provides more control over image sources and aligns with container best practices.
apps/webapp/app/root.tsx (1)
59-59: LGTM! Proper environment variable exposure to client-side.The addition correctly exposes the
TRIGGER_CLI_TAGenvironment variable through the loader data, following the established pattern and coding guidelines for accessing environment variables via theenvexport.hosting/k8s/helm/templates/tests/test-postgresql.yaml (2)
1-1: LGTM! Consistent deployment flag refactoring.The change to use
.Values.postgres.deployaligns with the standardized deployment flag pattern being applied across all services in the Helm chart.
14-14: LGTM! Improved image specification consistency.The fully qualified image path using registry, repository, and tag values maintains consistency with other service test templates and provides better deployment flexibility.
hosting/k8s/helm/templates/tests/test-s3.yaml (3)
1-1: LGTM! Deployment flag updated to match S3 configuration.The change from
.Values.minio.enabledto.Values.s3.deploycorrectly aligns with the refactoring that renamed MinIO configuration to a generic S3 configuration.
5-5: LGTM! Consistent naming updates for S3 configuration.The pod and container names were appropriately updated from "minio" to "s3" to reflect the service configuration changes.
Also applies to: 13-13
18-20: ```shell
#!/bin/bash
set -eecho "1) List all template files that mention 'minio':"
fd -e yaml -I "minio" hosting/k8s/helm/templatesecho
echo "2) Look for Service resources in those files:"
fd -e yaml -I "minio" hosting/k8s/helm/templates -x rg -n "kind:[[:space:]]*Service" {} ;echo
echo "3) Extract metadata.name entries to see the actual service names:"
fd -e yaml -I "minio" hosting/k8s/helm/templates -x rg -n "metadata:|name:" {} ;</details> <details> <summary>docs/self-hosting/kubernetes.mdx (5)</summary> `184-184`: **LGTM: Consistent naming convention update** The change from `extraEnv` to `extraEnvVars` aligns with Bitnami chart conventions and improves clarity about the configuration purpose. --- `205-212`: **LGTM: Simplified external service configuration** The unified approach using `deploy: false` and `external:` configuration is cleaner than the previous `enabled`/`externalConnection` pattern. This simplifies the configuration model and improves user experience. --- `264-274`: **LGTM: Consistent configuration pattern across services** The registry configuration follows the same `deploy`/`external` pattern used for other services, maintaining consistency throughout the chart. --- `287-297`: **LGTM: Clear S3-compatible storage configuration** The MinIO external configuration is well-documented and follows the established pattern. The alias from `minio` to `s3` makes the purpose clearer. --- `306-333`: **LGTM: Authentication configuration updates** All authentication examples consistently use `extraEnvVars` instead of `extraEnv`, maintaining consistency with the refactored chart structure. </details> <details> <summary>apps/webapp/app/components/SetupCommands.tsx (2)</summary> `4-4`: **LGTM: Enhanced CLI version configurability** The replacement of hardcoded `v3PackageTag` with the dynamic `useTriggerCliTag()` hook enables runtime configuration of CLI versions through the `TRIGGER_CLI_TAG` environment variable. This improves flexibility for different deployment environments and aligns with the PR's objective of making the CLI tag display configurable. Also applies to: 71-71, 121-121, 167-167 --- `73-74`: **LGTM: Consistent dynamic tag usage across all CLI commands** All CLI command strings now properly interpolate the dynamic `triggerCliTag` value, ensuring consistent versioning across init, dev, and login commands for all package managers (npm, pnpm, yarn). Also applies to: 143-143, 151-151, 159-159, 189-189, 197-197, 205-205 </details> <details> <summary>hosting/k8s/helm/Chart.yaml (2)</summary> `19-37`: **LGTM: Excellent architectural improvement with Bitnami dependencies** The addition of external Bitnami chart dependencies is a significant improvement that: - Reduces maintenance burden by leveraging well-maintained upstream charts - Improves compatibility across different environments - Enhances configurability of infrastructure services - Follows Helm best practices for dependency management The conditional deployment flags and aliases are well-structured and align with the configuration refactoring throughout the chart. --- `5-6`: **Verify the appVersion change pattern** The appVersion changed from semantic versioning (`v4.0.0-v4-beta.21`) to a different pattern (`trigger-helm-rc.0`). Please confirm this change is intentional and aligns with your versioning strategy. ```shell #!/bin/bash # Check if the new appVersion pattern is used elsewhere in the codebase rg -A 2 -B 2 "trigger-helm-rc".github/workflows/release-helm.yml (2)
32-38: LGTM: Essential workflow steps for dependency managementThe addition of dependency build and extraction steps is necessary to support the new Bitnami chart dependencies. These steps ensure:
- Dependencies are properly downloaded and available during linting/testing
- Chart archives are extracted for template processing
- Both lint and release jobs have consistent dependency handling
Also applies to: 71-77
134-134: LGTM: Improved shell command robustnessQuoting the version argument prevents potential issues with shell interpretation of special characters in version strings.
hosting/k8s/helm/templates/secrets.yaml (1)
18-18: LGTM: Consistent configuration flag updatesThe conditional logic correctly updates to use the new unified configuration flags:
registry.deployreplacesregistry.enabledfor deployment controlregistry.external.auth.enabledreplacesregistry.externalConnection.auth.enabledfor external authenticationThese changes maintain the same functional behavior while aligning with the standardized configuration model used throughout the chart.
Also applies to: 38-38
hosting/k8s/helm/values-production-example.yaml (1)
82-84: Example looks goodThe new
clickhouse.secureflag and the rebrandeds3section align with the chart changes and keep prod defaults explicit.Also applies to: 96-103
hosting/k8s/helm/templates/NOTES.txt (3)
61-70: Configuration check logic correctly updated.The changes properly implement the new deployment model where
.deploydetermines if a service is deployed internally, and external configuration is accessed via.externalinstead of.externalConnection.
71-85: Service configuration consistently updated.The Electric, ClickHouse, and S3 services follow the same pattern as PostgreSQL and Redis, maintaining consistency across the template. The MinIO to S3 renaming is properly reflected.
86-96: Registry configuration updated with helpful localhost warning.The registry configuration follows the established pattern, and the localhost warning provides valuable guidance to prevent deployment issues in non-local environments.
hosting/k8s/helm/templates/webapp.yaml (3)
52-84: Health probes properly implemented with full configurability.The implementation provides complete control over all Kubernetes health probe parameters and correctly uses conditional rendering based on the enabled flag. This aligns with the PR objective of making probes fully configurable.
221-221: ClickHouse URLs properly configured using helpers.The use of dedicated helpers for ClickHouse URL generation centralizes the logic and supports both regular and replication connections.
Also applies to: 227-227
234-236: Environment variable configuration renamed for clarity.The renaming from
extraEnvtoextraEnvVarsimproves clarity and follows common Helm chart naming conventions.hosting/k8s/helm/README.md (3)
7-18: Prerequisites section properly documents dependency setup.The new prerequisites section provides clear instructions for building and extracting Helm dependencies, which is essential now that the chart uses Bitnami charts as dependencies.
222-426: Excellent documentation for persistence and health probes.The documentation provides comprehensive coverage of:
- Basic persistence configuration for Bitnami services
- Full Bitnami-style persistence for internal services
- Complete health probe configuration examples for all components
This will greatly help users understand and configure these features.
669-694: Production persistence examples are comprehensive and realistic.The examples show appropriate storage sizes and include important production considerations like backup annotations. The full Bitnami-style configuration for the registry is particularly helpful.
hosting/k8s/helm/templates/_helpers.tpl (6)
98-118: PostgreSQL helpers properly implement the new deployment model.The hostname helper correctly prioritizes direct host configuration over deployment-based naming. The connection string helper comprehensively includes all connection parameters and properly distinguishes between deployed and external configurations.
121-144: Redis helpers follow consistent pattern.The implementation mirrors the PostgreSQL approach, maintaining consistency across service helpers. The port defaulting logic is correct.
149-195: Electric and ClickHouse helpers well-implemented.The Electric helper correctly uses the deploy flag. The ClickHouse implementation is particularly good:
- Supports both HTTP and HTTPS based on secure flag
- Separate helpers for regular and replication connections
- Proper handling of both deployed and external configurations
197-224: Excellent backward compatibility for MinIO to S3 transition.The approach of keeping MinIO helpers as wrappers to S3 helpers ensures existing configurations continue to work while clearly marking them as deprecated. This is a smooth migration path.
239-256: Registry and PostgreSQL host helpers correctly updated.Both helpers properly implement the deploy flag pattern and construct appropriate connection details for their specific use cases.
291-306: Image pull secret helper properly updated for new configuration structure.The helper correctly handles authentication for both deployed and external registries, following the new configuration pattern with deploy flags and external auth settings.
hosting/k8s/helm/values.yaml (7)
24-24: Webapp configuration properly updated.The extraEnvVars renaming is consistent throughout, and the health probe configuration provides comprehensive control with sensible defaults. The examples in extraEnvVars are helpful for users.
Also applies to: 109-148
242-277: Supervisor configuration consistent with webapp pattern.The extraEnvVars renaming and health probe configuration follow the established pattern, with appropriate defaults for a supervisor component.
331-351: Redis configuration correctly updated.The configuration implements the deploy flag pattern and explicitly sets standalone architecture, which is appropriate for single-node deployments.
354-411: Electric configuration properly updated.The configuration correctly implements all the standard patterns: deploy flag, health probes, external configuration, and extraEnvVars renaming.
414-465: ClickHouse configuration excellently structured.The configuration provides:
- Proper Bitnami chart integration
- Secure connection support
- Single-node setup appropriate for development
- Correct XML format for configuration overrides
- Comprehensive external connection options
467-489: S3 configuration properly renamed and structured.The renaming from MinIO to S3 better represents the flexibility to use any S3-compatible storage. The configuration follows the established deploy/external pattern.
490-584: Registry configuration comprehensive with appropriate warnings.The configuration provides:
- Clear experimental status warning
- Full Bitnami-style persistence with all options
- Complete health probe configuration
- Proper external registry support
The detailed persistence options give users full control over PVC configuration.
Main helm changes:
extraEnv -> extraEnvVarsenabled -> deployexternalConnection -> external(external config will be used ifdeploy: false)persistenceconfig has been extended to use full bitnami style for all servicesAlso adds an optional
TRIGGER_CLI_TAGenv var to control tag shown for setup commands in the webapp.