fix(helm): add missing gateway env vars, deploy control, and sidecar support

[JARVIS-coding-Agent]

Context

Closes #692

The v0.8.2 Helm chart gateway templates (added in #677) are missing critical env var injection for Telegram and LINE adapters, have no sidecar support, and couple config generation with deployment creation.

Summary

This PR fixes all four issues reported in #692:

1. P0: Missing env vars — Gateway template now injects TELEGRAM_BOT_TOKEN, TELEGRAM_SECRET_TOKEN, TELEGRAM_WEBHOOK_PATH, LINE_CHANNEL_SECRET, LINE_CHANNEL_ACCESS_TOKEN via secretKeyRef
2. Config/deployment coupling — New gateway.deploy flag (default: true). Set to false for config-only mode (agent gets [gateway] config block without creating Gateway Deployment/Service)
3. No sidecar support — Added extraContainers, extraVolumes, extraVolumeMounts to gateway Deployment (e.g. for cloudflared tunnel sidecar)
4. Per-agent deployment — Users can set deploy: false on all but one agent to share a single gateway instance

Changes

• charts/openab/templates/gateway.yaml — Add telegram/LINE env vars, deploy guard, extraContainers/extraVolumes/extraVolumeMounts, nodeSelector/affinity/tolerations
• charts/openab/templates/gateway-secret.yaml — Add telegram-bot-token, telegram-secret-token, line-channel-secret, line-channel-access-token keys
• charts/openab/values.yaml — Add deploy, telegram.*, line.*, extraContainers, extraVolumeMounts, extraVolumes, nodeSelector, tolerations, affinity fields with documentation comments
• charts/openab/tests/gateway_test.yaml — Add 18 new tests across 3 suites (config rendering, deployment rendering, secret rendering). 28 gateway tests total, 64/64 chart-wide passing.

Design Decisions

• gateway.deploy instead of top-level shared gateway: Minimal change that solves the coupling problem. Users who want a shared gateway set deploy: false on all agents except one (or deploy gateway externally). A top-level shared gateway abstraction is a larger architectural change better suited for a follow-up.
• Secrets in gateway Secret, not agent Secret: Telegram/LINE credentials are gateway-side (the gateway binary reads them), so they belong in the gateway Secret. GATEWAY_WS_TOKEN remains in the agent Secret (shared between agent and gateway) — single source of truth preserved.
• No required validation on telegram.botToken: The latest gateway binary uses .ok() (optional) for TELEGRAM_BOT_TOKEN, not .expect(). Missing token means the Telegram adapter is simply not enabled, not a crash. Adding required would block Teams-only or LINE-only deployments.

Verification: deploy: false does not break agent Secret

When gateway.deploy: false:

• Skipped: Gateway Deployment, Gateway Service, Gateway Secret (telegram/LINE/Teams credentials)
• Not affected: Agent Secret (secret.yaml) which holds gateway-ws-token — this is controlled by gateway.enabled + gateway.token, independent of gateway.deploy
• Not affected: Agent ConfigMap [gateway] config block — still rendered when gateway.enabled: true
• Result: Agent can connect to an external gateway using the [gateway] config and GATEWAY_WS_TOKEN from its own Secret. No dangling secretKeyRef references.

Verified by helm-unittest: does not render Deployment when deploy is false and does not render when deploy is false (Secret) both pass while config rendering tests confirm [gateway] block is still generated.

Note on P0 severity

Issue #692 reported TELEGRAM_BOT_TOKEN as causing panic on startup. This was true in older gateway versions, but the current main branch (gateway/src/main.rs) uses std::env::var("TELEGRAM_BOT_TOKEN").ok() — the adapter is silently disabled rather than crashing. The fix is still necessary (users cannot configure Telegram via Helm without it), but severity is P1 (silent feature failure) rather than P0 (startup crash).

Discord Discussion URL: https://discord.com/channels/1491295327620169908/1499911655142985888

[JARVIS-coding-Agent]

Group Review Summary — PR #693

Reviewers

• FRIDAY ✅ LGTM
• VISION ✅ LGTM
• SHURI ✅ LGTM

---

Issues Fixed (Issue #692)

#	Problem	Severity	Solution
1	Per-agent gateway Deployment — each agent with gateway.enabled: true creates its own Gateway pod	Design	New gateway.deploy flag. Set deploy: false on agents that should share an external gateway
2	Missing TELEGRAM/LINE env vars — gateway template only injected TEAMS + GATEWAY_WS_TOKEN	P1*	Added TELEGRAM_BOT_TOKEN, TELEGRAM_SECRET_TOKEN, TELEGRAM_WEBHOOK_PATH, LINE_CHANNEL_SECRET, LINE_CHANNEL_ACCESS_TOKEN via secretKeyRef
3	No sidecar support — gateway Deployment had no extraContainers	Feature gap	Added extraContainers, extraVolumes, extraVolumeMounts, nodeSelector, affinity, tolerations
4	Config/deployment coupled — gateway.enabled controls both configmap and Deployment	Design	gateway.deploy: false skips Deployment/Service/Secret while preserving [gateway] config block

* Originally reported as P0 (startup panic), but latest main uses .ok() for TELEGRAM_BOT_TOKEN — adapter is silently disabled, not crashed. Severity downgraded to P1.

---

Review Rounds

Round 1 — FRIDAY

• Problem A: toString guard on deploy flag — suggested | default true. After testing, confirmed default true breaks boolean false (Helm treats false as falsy). Kept toString pipe pattern, consistent with chart helpers (agentEnabled, persistenceEnabled). ✅ Resolved.
• Problem B: Single-arg and on $hasTelegram/$hasLine — misleading syntax. Removed, changed to direct assignment. ✅ Resolved (commit 60d5d1c).

Round 2 — VISION

• nindent 8 on extraContainers: Suggested changing to nindent 6. Verified against deployment.yaml — nindent 8 is correct (container list item level). nindent 6 would produce invalid pod spec. ❌ Not a bug.
• PR description: Requested explicit verification of deploy: false + Secret dependency. ✅ Added "Verification" section to PR description.
• All other checks passed: Secret key consistency, deploy logic, values.yaml defaults, test coverage, toString robustness.

Round 3 — SHURI

• Point 1 — fail guard for missing tokens: Rejected by FRIDAY + VISION. Gateway binary uses .ok() (optional) for all platform tokens. Adding fail would block legitimate Teams-only or LINE-only deployments. → Follow-up issue.
• Point 2 — Configurable probe parameters: Rejected by FRIDAY + VISION. Hardcoded probes are from PR feat(helm): add Gateway Deployment + Service templates #677, not introduced by this PR. Enhancement, not bug fix. → Follow-up issue.
• Point 3 — deploy: false Secret dependency: Confirmed GATEWAY_WS_TOKEN lives in agent Secret (not gateway Secret). deploy: false only skips gateway Deployment/Service/Secret. Agent Secret unaffected. ✅ Verified and documented in PR description.

---

Test Results

• 64/64 passing (7 suites)
• 28 gateway-specific tests across 3 suites: config rendering, deployment rendering, secret rendering
• Key test cases: deploy: false skips resources, telegram/LINE env var injection, sidecar rendering, secret creation conditions

Files Changed

• charts/openab/templates/gateway.yaml — env vars, deploy guard, sidecar support
• charts/openab/templates/gateway-secret.yaml — telegram/LINE secrets
• charts/openab/values.yaml — new gateway config fields
• charts/openab/tests/gateway_test.yaml — 18 new tests

Suggested Follow-ups (out of scope for this hotfix)

1. Configurable probe parameters (gateway.livenessProbe.*)
2. Fail-fast validation when partial platform config is detected
3. Top-level shared gateway abstraction (independent Chart-level resource)
4. gateway/src/main.rs — handle broadcast::RecvError::Lagged (silent message loss)

[shaun-agent]

OpenAB PR Screening

This is auto-generated by the OpenAB project-screening flow for context collection and reviewer handoff.
Click 👍 if you find this useful. Human review will be done within 24 hours. We appreciate your support and contribution 🙏

• Title: fix(helm): add missing gateway env vars, deploy control, and sidecar support
• Source: fix(helm): add missing gateway env vars, deploy control, and sidecar support #693
• Status: moved to PR-Screening
• Generated at: 2026-05-02T11:02:37.878Z
• Discord thread: https://discord.com/channels/1488041051187974246/1500090001549951098

Screening report

## Intent

PR #693 is trying to make the Helm chart’s gateway deployment usable for Telegram, LINE, external/shared gateway setups, and gateway sidecars.

The operator-visible problem is concrete: Helm users cannot currently configure Telegram or LINE gateway credentials through the chart, cannot run common tunnel sidecars such as cloudflared, and cannot render agent gateway config without also creating a Gateway Deployment/Service.

Feat

This is primarily a Helm chart fix with small deployment feature additions.

It adds missing Telegram and LINE environment variables from Kubernetes Secrets, introduces gateway.deploy to separate config rendering from gateway workload creation, and adds gateway extraContainers, extraVolumes, extraVolumeMounts, plus scheduling controls.

Who It Serves

Primary beneficiary: deployers and agent runtime operators using the Helm chart.

Secondary beneficiaries: maintainers and reviewers, because the PR adds helm-unittest coverage around gateway rendering, secret rendering, and config-only behavior.

Rewritten Prompt

Update the OpenAB Helm chart so gateway configuration and gateway deployment can be controlled independently.

Implement optional Telegram and LINE credential support for the gateway by adding values, Secret keys, and secretKeyRef environment variables. Add gateway.deploy, defaulting to true, so gateway.enabled=true can still render agent [gateway] config while skipping Gateway Deployment, Service, and gateway Secret when deployment is externally managed. Add gateway sidecar and scheduling extension points: extraContainers, extraVolumes, extraVolumeMounts, nodeSelector, affinity, and tolerations.

Preserve existing behavior by default. Add helm-unittest coverage for normal gateway deployment, deploy: false, secret key rendering, Telegram/LINE env var injection, sidecar rendering, and absence of dangling Secret references.

Merge Pitch

This is worth moving forward because it closes real deployment gaps in the v0.8.2 Helm chart and removes the need for users to fork or patch manifests for common gateway setups.

Risk profile is moderate-low: the changes are mostly Helm template conditionals and values additions, with backward-compatible defaults. The likely reviewer concern is semantic drift between gateway.enabled and gateway.deploy, especially around which Secrets are rendered and whether shared gateway mode is clear enough for multi-agent deployments.

Best-Practice Comparison

OpenClaw principles partially apply. Explicit delivery routing is relevant because the chart should make it clear whether agents connect to an in-chart gateway or an externally managed/shared gateway. Isolated executions are loosely relevant through support for separate gateway workloads and sidecars. Gateway-owned scheduling, durable job persistence, retry/backoff, and run logs do not directly fit this Helm chart PR.

Hermes Agent principles also partially apply. The gateway daemon tick model, file locking, atomic writes, fresh session per scheduled run, and self-contained scheduled prompts are not directly relevant. The closest applicable principle is operational isolation: gateway.deploy=false enables an external gateway lifecycle while preserving agent config, which is consistent with separating runtime ownership from generated configuration.

Implementation Options

1. Conservative option: merge only the missing Telegram and LINE env vars and Secret keys, plus tests. Defer gateway.deploy, sidecars, and scheduling knobs.

2. Balanced option: merge the PR shape as proposed: credential injection, gateway.deploy, sidecar hooks, scheduling fields, and helm-unittest coverage.

3. Ambitious option: introduce a top-level shared gateway abstraction with first-class multi-agent routing, one gateway Deployment per release, explicit external gateway mode, values schema validation, and migration docs.

4. Staged option: merge credential injection and gateway.deploy now, then split sidecar/scheduling support into a follow-up PR if reviewers want a smaller blast radius.

Comparison Table

Option	Speed to ship	Complexity	Reliability	Maintainability	User impact	Fit for OpenAB right now
Conservative env-var fix	High	Low	High	High	Medium	Good, but incomplete
Balanced PR as proposed	Medium	Medium	Good with tests	Good	High	Best fit
Ambitious shared gateway model	Low	High	Potentially high later	Medium	Very high	Too large for this item
Staged split	Medium-high	Low-medium	High	High	Medium-high	Good if reviewers want smaller scope

Recommendation

Advance the balanced option, with careful review of gateway.enabled versus gateway.deploy semantics.

It solves the reported deployment problems without forcing a larger gateway architecture redesign. The PR should be reviewed around render behavior, Secret ownership, and upgrade compatibility. A future follow-up can introduce a first-class shared gateway model if multi-agent gateway ownership becomes common enough to justify a larger chart abstraction.

[chaodu-agent]

LGTM ✅ — Well-structured fix addressing all four issues from #692 with clean implementation, proper secret separation, backward compatibility, and thorough test coverage (18 new tests, 64/64 chart-wide passing).

Baseline Check

Main has gateway templates with only Teams env vars, no deploy flag, no sidecar/scheduling support.

PR adds: deploy flag for config-only mode, Telegram env vars (BOT_TOKEN, SECRET_TOKEN, WEBHOOK_PATH), LINE env vars (CHANNEL_SECRET, CHANNEL_ACCESS_TOKEN), extraContainers/extraVolumes/extraVolumeMounts, nodeSelector/affinity/tolerations.

No stale overlap with main — all changes are net-new.

四問框架

1. What problem? Gateway templates missing env vars for Telegram/LINE adapters, no way to disable gateway deployment while keeping config, no sidecar/scheduling support.
2. How? Adds deploy boolean gate, platform-specific env vars with proper secret separation, and standard K8s extensibility fields (extraContainers, nodeSelector, etc.).
3. Alternatives? N/A — straightforward gap-fill for existing gateway template architecture.
4. Best approach? Yes. Follows existing chart patterns, correct secret separation (gateway secrets in gateway Secret, agent secrets in agent Secret).

Traffic Light

🟢 INFO — Excellent test coverage (18 new tests across 3 suites including negative cases)
🟢 INFO — Correct secret separation and backward compatibility
🟢 INFO — Model PR description with design decisions and severity analysis
🟢 INFO — Clean removal of redundant $agentD redeclaration
🟡 NIT — Empty string defaults for telegram/line fields in values.yaml (cosmetic)
🟡 NIT — deploy guard string comparison works correctly but could use a CLI usage note

[chaodu-agent]

超渡法師 Review — PR #693

APPROVE ✅ — Clean, well-scoped Helm fix that correctly wires Telegram/LINE env vars into the gateway template. Ready to merge.

Baseline Check

Main branch (v0.8.2): Gateway templates (#677) only inject GATEWAY_WS_TOKEN and Teams env vars. No Telegram/LINE env var injection exists. No deploy flag, no sidecar support.

Gateway source (gateway/src/main.rs): Confirmed env var names match exactly:

• TELEGRAM_BOT_TOKEN — .ok() (optional, not panic)
• TELEGRAM_SECRET_TOKEN — .ok() (optional)
• TELEGRAM_WEBHOOK_PATH — .unwrap_or_else(|_| "/webhook/telegram")
• LINE_CHANNEL_SECRET — .ok() (optional)
• LINE_CHANNEL_ACCESS_TOKEN — .ok() (optional)

Issue #692 severity correction: PR correctly notes that the current main uses .ok() (P1 silent failure), not .expect() (P0 crash). The issue description quotes a panic message from an older version.

Four-Question Analysis

1. What problem does it solve?

Gateway templates from #677 only wired Teams env vars. Telegram and LINE adapters cannot be configured via Helm — users must manually inject env vars or use external secret management. Also, no way to decouple config generation from deployment creation, and no sidecar support for cloudflared tunnels.

2. How does it solve it?

• Telegram/LINE env vars — secretKeyRef injection in gateway.yaml, secrets stored in gateway-secret.yaml
• deploy flag — ne (($cfg.gateway).deploy | toString) "false" guard on Deployment/Service/Secret. ConfigMap [gateway] block is unaffected (controlled by gateway.enabled only)
• Sidecar support — extraContainers, extraVolumes, extraVolumeMounts on gateway pod
• Scheduling — nodeSelector, tolerations, affinity

3. What was considered?

• Top-level shared gateway abstraction — deferred (larger architectural change)
• required validation on telegram.botToken — correctly rejected (gateway uses .ok(), missing token = adapter disabled, not crash)

4. Is this the best approach?

Yes. Minimal, focused fix that follows existing chart patterns. The deploy flag is a clean solution for config/deployment decoupling without introducing a top-level shared gateway abstraction.

Detailed Findings

🟢 INFO — Well done

1. Correct secret placement — Telegram/LINE credentials go in the gateway Secret (gateway binary reads them), not the agent Secret. GATEWAY_WS_TOKEN stays in agent Secret. Single source of truth preserved.

2. deploy guard is correct — Uses ne (toString) "false" which defaults to true when key is absent. ConfigMap rendering is unaffected (only checks gateway.enabled). Verified: deploy: false skips Deployment + Service + Gateway Secret, but agent Secret still has gateway-ws-token and ConfigMap still renders [gateway] block.

3. Removed duplicate $agentD declaration — Line 46 of gateway.yaml removes the redundant $agentD := dict ... that was already declared at the top of the template. Good cleanup.

4. Comprehensive test coverage — 18 new tests across 3 suites (config rendering, deployment rendering, secret rendering). Tests cover positive cases, negative cases (no platform secrets → no Secret), and the deploy: false path.

5. Consistent with existing patterns — extraContainers/extraVolumes/extraVolumeMounts follow the same pattern used in the main agent deployment template (fix(discord/slack/helm): empty allowed_channels denies all channels (secure by default) #398).

🟡 NIT — Non-blocking

1. values.yaml defaults — telegram.botToken: "" and line.channelSecret: "" default to empty strings. The template guards ($hasTelegram := (($cfg.gateway).telegram).botToken) treat empty string as falsy in Go templates, so this works correctly. However, using # botToken: "" (commented out) would be more explicit about "not configured" vs "configured with empty value". Same pattern as the existing teams section.

2. Missing helm.sh/resource-policy: keep on gateway Secret when only Telegram/LINE secrets — The existing Teams-only Secret already has this annotation, and the PR preserves it. Good.

🔴 SUGGESTED CHANGES

None.

---

Verdict: Clean, well-tested Helm fix. Env var names verified against gateway source. deploy flag logic is correct. Test coverage is thorough. No blocking issues.