feat(helm): add Temporal workflow engine support (required since Postiz v2.12.0)#21
feat(helm): add Temporal workflow engine support (required since Postiz v2.12.0)#21pirona wants to merge 4 commits into
Conversation
- Chart.yaml: bump to version 1.1.0, appVersion v2.21.8 - values.yaml: add temporal section (enabled/address/namespace/tls/apiKey/postgresql), expand env (~40 non-sensitive vars) and secrets (~60 sensitive vars) to match current Postiz documentation — covers all social providers, email SMTP, OAuth OIDC, AI/generation, analytics, MCP, payments, short-link services - postiz-config.yaml: inject TEMPORAL_ADDRESS (auto-computed or override), TEMPORAL_NAMESPACE and TEMPORAL_TLS when temporal.enabled or address is set - temporal-deployment.yaml: temporalio/auto-setup:1.28.1, postgres12 backend, ES disabled, dynamicconfig volume mount, liveness/readiness probes - temporal-service.yaml: ClusterIP on port 7233 (gRPC) - temporal-dynamicconfig.yaml: ConfigMap with development-sql.yaml content - temporal-init-job.yaml: post-install/upgrade Job that creates the temporal PostgreSQL user via the postgres superuser before Temporal starts - temporal-secret.yaml: Secret for temporal PostgreSQL credentials - NOTES.txt: post-install guidance, search-attribute creation reminder, multi-replica/local-storage warning, backup reminder Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
When temporal.postgresql.user == postgresql.auth.username, the user already exists with CREATEDB — temporalio/auto-setup handles database creation itself. The init job only runs for a distinct dedicated user. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Opt-in rather than opt-out: existing deployments that do not need the bundled Temporal instance are unaffected by a plain helm upgrade. Users who want the self-hosted setup explicitly set temporal.enabled=true. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Warning Review limit reached
More reviews will be available in 40 minutes and 15 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more credits in the billing tab to continue. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughBumps the Postiz Helm chart from ChangesPostiz Helm Chart — Temporal Integration and Expansion
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Actionable comments posted: 7
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@charts/postiz/templates/NOTES.txt`:
- Around line 4-5: The NOTES.txt file hard-codes the https:// scheme and only
displays the host from the ingress configuration, but the actual ingress
configuration may support HTTP-only setups and custom paths. Update the ingress
URL output in the NOTES.txt template to dynamically use the correct scheme (http
or https based on TLS settings) and include the path prefix from the first
ingress host entry. Review the ingress template structure and .Values.ingress
configuration to determine how TLS is enabled and how paths are defined, then
construct the full URL accordingly instead of hard-coding https://.
- Around line 6-10: The kubectl port-forward example in the else block hardcodes
port 80 as the service port, but the actual service port is configurable via
.Values.service.port. Replace the hardcoded "80" in the port-forward command
with the templated value from .Values.service.port so that the forwarding works
correctly when the service port is customized to any value other than 80.
- Around line 17-25: The kubectl commands in the NOTES.txt template (kubectl get
pods, kubectl logs job, and kubectl exec deploy) do not specify a namespace
flag, causing them to default to the current namespace and fail for non-default
installations. Add the `-n {{ .Release.Namespace }}` flag to each of these
kubectl commands to scope them to the actual release namespace where Postiz is
deployed, ensuring the commands execute against the correct namespace regardless
of the user's current context.
In `@charts/postiz/templates/postiz-config.yaml`:
- Around line 15-17: The external Temporal configuration block (the else if
.Values.temporal.address conditional) currently only exports TEMPORAL_ADDRESS
but ignores namespace and TLS settings from values. Add conditional exports for
TEMPORAL_NAMESPACE and TEMPORAL_TLS within the same else if block, checking if
.Values.temporal.namespace and .Values.temporal.tls exist respectively, so that
external and Cloud Temporal setups have access to all required configuration
parameters.
In `@charts/postiz/templates/temporal-init-job.yaml`:
- Line 35: The PGHOST environment variable is hardcoded to {{ .Release.Name
}}-postgresql at line 35 and line 60, but this may differ from the actual
database host configured in the Temporal runtime through
.Values.temporal.postgresql.seeds. Update both PGHOST assignments to use the
same source as the Temporal runtime configuration (reference
.Values.temporal.postgresql.seeds) so that the init job connects to the same
database endpoint as the Temporal deployment, preventing inconsistency when
users override the postgresql.seeds value.
- Around line 43-51: The unquoted heredoc delimiter at the psql command (<<-SQL)
causes the shell to expand $TEMPORAL_USER and $TEMPORAL_PWD variables before
passing the SQL to psql, which breaks if credentials contain special characters
like quotes. Change the heredoc to use a quoted delimiter (<<-'SQL') to prevent
shell expansion, then use psql's --set option to pass the variables securely
into the SQL context, allowing them to be referenced as SQL variables within the
DO block instead of relying on shell variable substitution.
In `@charts/postiz/values.yaml`:
- Around line 67-70: Remove the hardcoded default passwords from the values.yaml
file by replacing the postgresPassword value (currently set to
postgres-admin-password around line 70) and any similar hardcoded temporal
password values (around line 104) with empty strings or null values to eliminate
predictable default credentials. Additionally, update the temporal-secret.yaml
template to add required field validation checks that ensure these password
values are explicitly provided when temporal.enabled is set to true, allowing
the deployment to fail fast with a clear error message rather than using
insecure defaults.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 46e88ff1-1e14-492c-a201-e7eb7a7f00ee
📒 Files selected for processing (9)
charts/postiz/Chart.yamlcharts/postiz/templates/NOTES.txtcharts/postiz/templates/postiz-config.yamlcharts/postiz/templates/temporal-deployment.yamlcharts/postiz/templates/temporal-dynamicconfig.yamlcharts/postiz/templates/temporal-init-job.yamlcharts/postiz/templates/temporal-secret.yamlcharts/postiz/templates/temporal-service.yamlcharts/postiz/values.yaml
NOTES.txt:
- Detect ingress scheme dynamically (http/https based on .Values.ingress.tls)
- Include first path in ingress URL output
- Use .Values.service.port in port-forward example instead of hardcoded 80
- Add -n {{ .Release.Namespace }} to all kubectl commands
postiz-config.yaml:
- Merge temporal enabled/external branches: external address now also emits
TEMPORAL_NAMESPACE and TEMPORAL_TLS, not just TEMPORAL_ADDRESS
temporal-init-job.yaml:
- Use .Values.temporal.postgresql.seeds as PGHOST source (with fallback to
bitnami sub-chart service name) so init job and runtime use the same host
- Switch to quoted heredoc (<<-'SQL') + psql --set to pass credentials as
psql variables, preventing shell expansion from breaking on special chars
temporal-secret.yaml:
- Add required validation: temporal.postgresql.password must be set explicitly
when temporal.enabled=true
values.yaml:
- Remove hardcoded default passwords (postgresPassword, temporal.postgresql.password)
replaced with empty strings to avoid predictable default credentials
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Add Temporal workflow engine support (required since Postiz v2.12.0)
Postiz has depended on Temporal since v2.12.0, but the Helm chart had no way to deploy or configure it. This PR adds opt-in Temporal support alongside the existing PostgreSQL/Redis sub-charts.
Context: I'm a Linux/Kubernetes systems engineer (CKA certified), running Postiz on a self-hosted K3s cluster. I needed Temporal support to get v2.x working. I want to be transparent: I used Claude Code (Anthropic's AI coding assistant) to help implement and validate this chart contribution. The design decisions, testing, and homelab use case are mine — I reached out to AI humbly to handle the Helm templating I wouldn't have had time to do properly on my own.
What this adds
New templates:
temporal-deployment.yaml—temporalio/auto-setupwith postgres12 backendtemporal-service.yaml— ClusterIP on port 7233 (gRPC)temporal-dynamicconfig.yaml— ConfigMap withdevelopment-sql.yamlpresettemporal-secret.yaml— PostgreSQL credentials for the Temporal usertemporal-init-job.yaml— post-install/post-upgrade Job that creates a dedicatedtemporalPostgreSQL role via the postgres superuser (skipped when reusing the main Postiz user)Updated:
values.yaml— newtemporal:section (opt-in,enabled: falseby default) + expandedenvandsecretsmaps covering all variables in the current Postiz documentation (~40 non-sensitive vars, ~60 sensitive vars)postiz-config.yaml— injectsTEMPORAL_ADDRESS,TEMPORAL_NAMESPACE,TEMPORAL_TLSwhen Temporal is enabled or an external address is setNOTES.txt— post-install guidance: search-attribute reminder, multi-replica warning, backup noteBehaviour
temporal.enabled: truetemporalio/auto-setup+ init jobtemporal.enabled: false+temporal.address: <host:port>temporal.enabled: false, no addressNon-breaking
temporal.enableddefaults tofalse— existing deployments are unaffected by a plainhelm upgrade.Tested on
temporalio/auto-setup:1.28.1temporaluser)🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Documentation
Chores