feat(chart): expose the worker task watchdog as worker.taskMaxRuntime

charts/plumber/Chart.yaml

@@ -2,8 +2,8 @@ apiVersion: v2
 name: plumber
 description: Helm chart for Plumber
 type: application
-version: "1.5.0"
-appVersion: "1.5.0"
+version: "1.5.1"
+appVersion: "1.5.1"
 home: https://github.com/getplumber/platform/
 maintainers:
   - name: devpro

charts/plumber/templates/deployment.yaml

@@ -107,6 +107,17 @@ spec:
                 fieldRef:
                   apiVersion: v1
                   fieldPath: status.hostIP
+            {{- if and (eq .name $.Values.worker.name) .taskMaxRuntime }}
+            {{- /*
+              Watchdog: the worker exits if any single task runs longer than
+              this. Opening an analysis enumerates every governed project from
+              GitLab as one task, so the limit has to exceed that enumeration or
+              the worker is killed mid-list, the task is retried, and the
+              analysis never starts. Only the worker reads it.
+            */}}
+            - name: JOBS_WORKER_TASK_MAX_RUNTIME
+              value: "{{ .taskMaxRuntime }}"
+            {{- end }}
             {{- if eq .type "backend" }}
             - name: JOBS_LISTEN_ADDR
               value: "0.0.0.0"

charts/plumber/values.yaml

@@ -188,6 +188,14 @@ worker:
   revisionHistoryLimit: 5
   args:
     - "--worker"
+  # -- Hard timeout for a single worker task, after which the worker exits and
+  # restarts (watchdog). Opening an analysis enumerates every governed project
+  # from GitLab as one task, so this has to be longer than that enumeration
+  # takes. On an estate of a few thousand projects it runs into several
+  # minutes, past the application default of 3m, and the symptom is an analysis
+  # that is accepted but stays at zero tasks while the worker restarts in a
+  # loop. Raise it further if your GitLab is slow or your estate is very large.
+  taskMaxRuntime: "20m"
   livenessEndpoint: "/job/health/alive"
   readinesspoint: "/job/health/ready"
   extraEnv: []