mirror of
https://github.com/authelia/authelia.git
synced 2026-10-28 09:34:52 +08:00
Amir Zarrinkafsh
5868c8a3dd
The Kubernetes suite has failed its first attempt in 21% of builds over the last four weeks, three times the rate of the other suites, rising from 5% to between 30% and 50% after #13097 lowered its `SetUpTimeout` from 12 minutes to 2. Automatic retries hid most of it, but each failed attempt costs a full suite run. Of the 270 failed attempts, two thirds were killed by that timeout while setup was still progressing normally: a passing setup takes 109 seconds on average and up to 135, and every attempt killed at 120 seconds reported its pods ready by 125. `SetUpTimeout` is now 3 minutes. `WaitPodsReady` treated a failed `kubectl` and a namespace with no pods as every pod being ready, because both list no pods. Setup could therefore report the cluster ready while the API server was restarting, or before the manifests creating the pods had been applied, and the first test then failed to load `HomeBaseURL`. Both now keep it waiting. k3s applies the manifests one at a time in path order and only retries a failed one on its next pass, so `namespace.yml` sorted after the `apps`, `authelia`, `ldap` and `mail` manifests that need the `authelia` namespace, and each of them failed with `namespaces "authelia" not found` before being applied again later. It is renamed `00-namespace.yml` so the namespace exists first. Pods also report ready before Traefik has loaded the ingress and middleware in front of them, and until then Traefik answers the host itself. Setup now waits until the ingress serves both `HomeBaseURL` and the portal's `/api/health`, since each has an ingress of its own. A setup that did time out left nothing to diagnose, because `WaitPodsReady` discards the `kubectl` output it polls. `OnSetupTimeout` now prints every pod, the cluster events and a description of the pods in the `authelia` namespace; 48 earlier attempts waited the full 5 minutes for pods that never became ready without saying which. `RunCommandWithTimeout` killed only the process it started, which for the suites is `go run`, so the setup it had built kept running into the teardown after the timeout. The command now runs in a process group of its own, the timeout kills the whole group, and interrupts are forwarded to it because the group no longer receives them from the terminal. --------- Signed-off-by: Amir Zarrinkafsh <3339418+nightah@users.noreply.github.com>