feat(chart): add extraContainers for arbitrary sidecar injection

[Vishesh-Gupta]

Summary

• Add a top-level extraContainers value so operators can inject arbitrary sidecar containers (log shippers, local proxies, exporters, etc.) without forking the chart.
• Render entries with Helm tpl on toYaml output so values can reference release/chart context (e.g. {{ .Release.Name }}).
• Append containers to main, worker, and webhook-processor deployments after the n8n container and after the optional task-runner sidecar where that sidecar exists.
• Extend values.schema.json and document usage in the chart README.

Test plan

• helm lint charts/n8n
• helm template with each example values file used in CI (minimal, minimal-with-docker, multi-main-queue, task-runners, keda-autoscaling, production-s3)
• helm template smoke test with --set-json for a minimal extraContainers entry

---

Summary by cubic

Add a top-level extraContainers value to inject arbitrary sidecars on n8n pods. Adds a CI overlay to template extraContainers against the minimal example to prevent regressions.

• New Features
  • Applies to main, worker, and webhook-processor deployments.
  • Renders entries via Helm tpl and appends after the n8n container (and task-runner if present).
  • Updated values.schema.json and README with usage and examples.
  • CI uses --dry-run=client and validates charts/n8n/ci/extraContainers-values.yaml over the minimal example.

^{Written for commit a3d1942. Summary will update on new commits. Review in cubic}

[cubic-dev-ai]

No issues found across 6 files

Architecture diagram

sequenceDiagram
    participant Admin as Operator/Admin
    participant Values as values.yaml
    participant Schema as values.schema.json
    participant Helm as Helm Template Engine
    participant DeployMain as Deployment-main.yaml
    participant DeployWorker as Deployment-worker.yaml
    participant DeployWebhook as Deployment-webhook-processor.yaml
    participant Pod as Pod Spec (main/worker/webhook)
    participant N8nContainer as n8n Container
    participant TaskRunner as Task Runner Sidecar (optional)
    participant ExtraContainers as Extra Sidecar Containers

    Note over Admin,ExtraContainers: PR: Adds extraContainers for arbitrary sidecar injection

    Admin->>Values: Set extraContainers array in values.yaml
    Values->>Schema: Validate against new schema definition
    Schema-->>Values: Validation passes (array of objects)

    Helm->>Values: Read extraContainers value
    Helm->>DeployMain: Process deployment-main.yaml template
    Helm->>DeployWorker: Process deployment-worker.yaml template
    Helm->>DeployWebhook: Process deployment-webhook-processor.yaml template

    Note over DeployMain,DeployWebhook: Each deployment follows the same pattern

    DeployMain->>Helm: Execute tpl(toYaml .) on extraContainers
    Note over Helm: tpl processes {{ .Release.Name }} etc. in container fields
    Helm-->>DeployMain: Rendered YAML for extra containers

    DeployMain->>Pod: Append containers after:
    Pod->>N8nContainer: Container 1 (always present)
    alt Task runner enabled
        Pod->>TaskRunner: Container 2 (optional)
    end
    Pod->>ExtraContainers: Container N+1 (new sidecar from extraContainers)

    alt Shared volumes needed
        ExtraContainers->>ExtraContainers: Mount volumes via extraVolumeMounts
        Note over ExtraContainers: Combines with extraVolumes for shared storage
    end

    Helm-->>DeployMain: Return complete pod spec
    Helm-->>DeployWorker: Return complete pod spec
    Helm-->>DeployWebhook: Return complete pod spec

    Admin->>Helm: helm lint / helm template (verify output)
    Helm-->>Admin: Validated template with sidecars injected

Loading

_{Re-trigger cubic}

[krider2010]

Nice addition, this is a clean non-breaking extension and lines up with the existing extraVolumes/extraEnv pattern. A couple of things I'd like to see before I approve:

1. The new table row says "Additional sidecar containers on all n8n pods" but the prose section below correctly scopes it to main, worker, and webhook-processor (not migration jobs etc.). Can you tighten the one-liner to match? Small thing, but it'll save someone a confused issue later.

2. None of the CI example values files exercise extraContainers, so the rendered-template CI won't cover this on every run. Could you add a minimal entry to one of the existing values files under charts/n8n/ci/ (or a new extraContainers-values.yaml) so we lock the behaviour in?

Couple of FYI-only things, not blocking:

• extraInitContainers is the natural sibling here — same tpl ... $ pattern would work. Not asking you to add it in this PR, just flagging as a likely follow-up.
• The schema is loose (items: { type: "object" }) which is the right call — full container-spec validation in Helm is more pain than it's worth, and the API server catches malformed entries.

Otherwise looks good — placement after the task-runner sidecar is correct, tpl ... $ gives the right root context, indentation checks out.

[Vishesh-Gupta]

Thanks for the review — addressed the blocking items:

1. README table — Updated the extraContainers row to say main, worker, and webhook-processor pods so it matches the prose (and avoids implying migration jobs or other resources).

2. CI coverage — Added charts/n8n/ci/extraContainers-values.yaml with a minimal busybox sidecar and a template-validation step that runs helm template with examples/minimal.yaml plus that overlay (only on the minimal matrix row so we do not duplicate work six times).

FYI acknowledgements (no code changes for these in this PR):

• Noted on extraInitContainers as the natural sibling / follow-up — same tpl + toYaml pattern.
• Agree on keeping the schema loose for container objects; API validation is the right backstop.

Let me know if you want the overlay wired to a different base example instead of minimal.yaml.

[krider2010]

Thanks! I'll review properly soon.