feat: INF-4136 make Deployment progressDeadlineSeconds configurable

[jmpalomares]

Summary

common.deployment hardcodes the Kubernetes default progressDeadlineSeconds (600s) — there's no way for a consuming chart's values.yaml to raise it. This surfaced in parcelLab/dbt (prod): after fixing a liveness-probe crash-loop by adding a startupProbe with a 1500s budget for a slow-starting container, the Deployment's rollout still gets marked Progressing=False / ProgressDeadlineExceeded — and ArgoCD surfaces that as Degraded — because the pod legitimately needs longer than 10 minutes to become Ready, independent of the probes. INF-4136

Description

• parcellab/common/templates/_deployment.tpl: added an optional progressDeadlineSeconds field on the Deployment spec, read via default .Values.progressDeadlineSeconds $service.progressDeadlineSeconds (same fallback pattern already used for strategy). When unset, the field is omitted entirely and Kubernetes applies its own 600s default — zero behavior change for existing consumers.
• parcellab/monolith/values.yaml: documented the new field with an explicit default of 600 (matching current behavior) so it's discoverable and consumers can bump it per-service or globally.
• Bumped parcellab/common to 1.3.13 and parcellab/monolith to 0.6.3 so chart-releaser publishes the change.

Motivation and Context

Lets slow-starting workloads (e.g. a container gated by a large startupProbe) set a realistic rollout deadline instead of always inheriting the 600s Kubernetes default, without needing a chart change per consumer. Companion fix in parcelLab/dbt will set progressDeadlineSeconds: 1800 in .chart/prod/values.yaml once this is released.

Testing

• helm lint parcellab/common and helm lint parcellab/monolith: pass.
• helm template parcellab/monolith --set name=test: renders progressDeadlineSeconds: 600 right after revisionHistoryLimit.
• helm template parcellab/monolith --set name=test --set progressDeadlineSeconds=1800: renders 1800.
• helm template parcellab/monolith --set name=test --set progressDeadlineSeconds=null: field omitted entirely (falls back to the Kubernetes default), confirming no behavior change for consumers who don't set it.

Breaking changes

None. Purely additive/optional field; existing consumers render identically until they opt in.

INF-4136

[Copilot]

Pull request overview

Adds configurability for Kubernetes Deployment progressDeadlineSeconds in the shared common.deployment template so slow-starting workloads can avoid ProgressDeadlineExceeded (and resulting ArgoCD Degraded) when they legitimately need more than 10 minutes to become Ready (INF-4136).

Changes:

• Add optional spec.progressDeadlineSeconds rendering to common.deployment, with global + per-workload override support.
• Document progressDeadlineSeconds in parcellab/monolith/values.yaml (defaulting to 600 for discoverability).
• Bump chart versions for release publishing (common 1.3.13, monolith 0.6.3).

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
parcellab/common/templates/_deployment.tpl	Conditionally renders progressDeadlineSeconds from values, keeping it omitted when unset.
parcellab/monolith/values.yaml	Documents the new progressDeadlineSeconds value (default 600).
parcellab/common/Chart.yaml	Version bump to publish the library chart change.
parcellab/monolith/Chart.yaml	Version bump to publish the consuming chart update/documentation.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.