feat(chart): add podLabels for extra labels on pod templates

[gkarach-conifers]

Summary

Adds a top-level podLabels value that is merged into the pod template metadata.labels of the main, worker, and webhook-processor Deployments, in addition to the chart's own selector labels.

Mirrors the existing podAnnotations pattern. Default {} preserves existing behavior — the {{- with }} block renders nothing when the value is empty.

Motivation

Several Kubernetes admission webhooks key off pod-level labels rather than annotations or service-account references, and have no other opt-in path:

• Azure AD Workload Identity injects federated-token env vars only when a pod carries azure.workload.identity/use=true.
• Istio, Linkerd, and similar service-mesh injectors gate on sidecar.istio.io/inject=true, linkerd.io/inject=enabled.
• External Prometheus scrape selectors and policy-as-code controllers often match on custom labels.

Today, deployments using this chart in any of those environments need a post-Helm kubectl patch workaround on each helm upgrade, because the pod templates only emit the chart's built-in selector labels and there's no way to add more from values. This PR closes that gap.

Changes

• charts/n8n/templates/deployment-main.yaml — adds {{- with .Values.podLabels }} ... {{- end }} under pod template metadata.labels
• charts/n8n/templates/deployment-worker.yaml — same
• charts/n8n/templates/deployment-webhook-processor.yaml — same
• charts/n8n/values.yaml — podLabels: {} declaration with explanatory comment and commented usage examples
• charts/n8n/README.md — new row in Key Configuration table

Selector labels are unchanged: the {{- with }} block only adds to template.metadata.labels, not selector.matchLabels or metadata.labels on the Deployment itself, so existing rolled-out workloads pick up the new labels on their next pod-template change without selector mismatch.

Test plan

• helm lint charts/n8n — passes
• helm template foo charts/n8n --set podLabels.foo=bar --set 'podLabels.example=test' ... confirms foo: bar and example: test land under pod template metadata.labels on all three Deployments (main, worker, webhook-processor) without disturbing selector labels
• Default render (podLabels: {}) — output is unchanged from current behavior except for the unchanged base labels (verified via diff)

Related

Same chart-affordance pattern as #111 (which added strategy: for the main Deployment in 1.4.0).

---

Summary by cubic

Add podLabels to merge extra labels into pod template metadata for the main, worker, and webhook-processor Deployments. Validates reserved keys and enforces string values; default {} keeps behavior unchanged.

• New Features

  • podLabels merged into pod template metadata.labels for main, worker, and webhook-processor.
  • Mirrors podAnnotations; empty {} renders nothing.
  • Leaves selector.matchLabels unchanged for safe rolling upgrades.

• Bug Fixes

  • Fail fast if any podLabels key overlaps chart-managed labels (app.kubernetes.io/*, helm.sh/chart).
  • Validate all podLabels values are strings to match Kubernetes map[string]string label requirements.

^{Written for commit a484043. Summary will update on new commits.}

[cubic-dev-ai]

3 issues found across 5 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="charts/n8n/templates/deployment-webhook-processor.yaml">

<violation number="1" location="charts/n8n/templates/deployment-webhook-processor.yaml:30">
P2: User-provided pod labels can overwrite selector labels, causing Deployment validation failures (`selector` vs template labels mismatch).</violation>
</file>

<file name="charts/n8n/templates/deployment-worker.yaml">

<violation number="1" location="charts/n8n/templates/deployment-worker.yaml:30">
P1: Unfiltered `podLabels` can override selector-bound labels, causing Deployment selector/template label mismatch.</violation>
</file>

<file name="charts/n8n/templates/deployment-main.yaml">

<violation number="1" location="charts/n8n/templates/deployment-main.yaml:34">
P2: User-supplied `podLabels` can override selector labels, causing Deployment selector/template label mismatch.</violation>
</file>

Architecture diagram

sequenceDiagram
    participant User as DevOps Engineer
    participant Helm as Helm Engine
    participant K8s as Kubernetes API
    participant Webhook as Admission Webhook (Istio/Azure/Linkerd)
    participant Pod as n8n Runtime Pods

    Note over User,Pod: Deployment Update Flow

    User->>Helm: helm upgrade (with podLabels in values.yaml)
    
    rect rgb(240, 240, 240)
    Note right of Helm: Template Rendering
    Helm->>Helm: Render n8n Labels (Standard)
    alt NEW: podLabels is not empty
        Helm->>Helm: NEW: Inject custom labels into pod.metadata.labels
    else podLabels is empty (default)
        Helm->>Helm: Render nothing (Existing behavior)
    end
    end

    Helm->>K8s: Apply Deployment (Main/Worker/Webhook-Processor)
    K8s->>K8s: Generate Pod from Template

    Note over K8s,Webhook: NEW: External Integration Trigger
    K8s->>Webhook: MutatingAdmissionWebhook Request (Pod Metadata)
    
    alt NEW: Metadata.labels matches webhook criteria
        Webhook-->>K8s: Patch Pod (e.g., Inject Sidecars or Env Vars)
    else No label match
        Webhook-->>K8s: Allow without modification
    end

    K8s->>Pod: Create Pod Instance
    
    Note over Pod: Result: Pod runs with both chart labels<br/>AND external identity/mesh capabilities

Loading

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review, or fix all with cubic.}

[cubic-dev-ai]

1 issue found across 2 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="charts/n8n/templates/_helpers.tpl">

<violation number="1" location="charts/n8n/templates/_helpers.tpl:146">
P2: Pod labels validation only guards reserved keys, not value types; non-string label values can pass Helm validation and fail against Kubernetes `map[string]string` labels.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review, or fix all with cubic.}