fix(ops): treat a CI-managed host as a skip, not a failed updater run
CI / check (push) Successful in 32s
CI / tests-unit (push) Successful in 1m57s
CI / tests-integration (push) Successful in 2m5s
CI / tests-imaging-browsers (push) Successful in 1m37s
CI / tests-ui (push) Failing after 3m13s
CI / preflight (push) Skipped
CI / deploy (push) Skipped

Commit 3c8abb6f made docker-update.sh exit 0 (SKIP) on a host owned by CI so
the cron does not report a failed deployment. The tests still expected a
nonzero exit for the ci-active/ci-green/ci-upstream scenarios, so five cases
failed.

- docker-update.test.ts: move the CI scenarios out of the non-zero group and
  assert the skip: exit 0, 'This host is managed by CI' in the output and no
  'compose up'. All three CI scenarios (both slot containers and the nginx
  upstream) now share one test.
- README.md: document the exit-0 skip.
This commit is contained in:
openhands committed 2026-10-14 21:59:42 +02:00
1 parent 3c8abb6fbf
commit ac23d7d1d9
2 files changed
+19 -18

No files matched your search

+14 -16
View File
@@ -188,29 +188,27 @@ describe("Docker clone updates", () => {
expect(r.calls).not.toContain("docker volume prune");
expect(r.calls).not.toContain("docker system prune");
});
it.each([
"dirty",
"ci-active",
"ci-green",
"ci-upstream",
"pull-failure",
"build-failure",
"migration-failure",
])("does not replace the container after %s", (scenario) => {
const r = simulate(scenario);
expect(r.status, r.output).not.toBe(0);
expect(r.calls).not.toContain("compose up");
});
it.each(["dirty", "pull-failure", "build-failure", "migration-failure"])(
"does not replace the container after %s",
(scenario) => {
const r = simulate(scenario);
expect(r.status, r.output).not.toBe(0);
expect(r.calls).not.toContain("compose up");
},
);
// Regressie: na een cutover naar het groene slot bestaat epicnext-cms-app
// niet meer en zag deze controle alleen een vrijgekomen blauwe container. De
// dagelijkse `docker-update.sh` startte toen een compose-replica op poort
// 3002 en blokkeerde elke volgende release. De blauwe container alleen
// controleren is dus geen bewijs dat de host niet door CI beheerd wordt.
it.each(["ci-green", "ci-upstream"])(
"refuses a compose deployment while CI owns the host (%s)",
//
// A host owned by CI is a legitimate no-op, not an error: the cron run must
// exit 0 so it does not look like a failed deployment.
it.each(["ci-active", "ci-green", "ci-upstream"])(
"skips the compose deployment while CI owns the host (%s)",
(scenario) => {
const r = simulate(scenario);
expect(r.status, r.output).not.toBe(0);
expect(r.status, r.output).toBe(0);
expect(r.output).toContain("This host is managed by CI");
expect(r.calls).not.toContain("compose up");
},