64ff5f508b
GATE 1 refuses to ladder an app that cannot prove a rung landed, and only mastodon, nextcloud and stalwart could. None of those are installed here, so the stepped upgrade — button or automatic — was unreachable for every app on the box. Three fixes. _updaterPrimaryContainer assumed the container is "<app>-service". It is a convention, not a rule: matrix names its anchor service matrix-synapse and stoat names its api (container stoat-api). The verifier therefore inspected a container that does not exist, saw no state, and could only time out — on exactly the stateful apps that most need verifying. It now reads the anchor service's container_name from the compose, buffering per service block because container_name may sit either side of the image line. Added updaterVerifyHttpVersion: poll the app over its PUBLISHED port from the host, pull the version from a JSON field or a response header, and require agreement three polls running. Probed from the host rather than `docker exec … curl` because half these images ship no curl at all (mattermost is one), so exec-based probing is a coin flip on the vendor's base image. Version comparison matches only the components both sides state, since tags and self-reported builds rarely share precision: v1.158.0 vs 1.158.0, 11.9 vs 11.9.1, 8.7.0 vs 8.7 all agree; 11.9 vs 11.10 does not. Each app hook is then three facts. Verified live: all three confirm at the version they are actually on, and all three REFUSE a version they are not — which is the property that makes stepping them safe. updaterUpgradeAuto now skips apps with no verifier instead of queueing a task that GATE 1 will reject, which would otherwise mean a failure notification every day for an app that was never eligible. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
20 lines
848 B
Bash
20 lines
848 B
Bash
#!/bin/bash
|
|
|
|
# Mattermost upgrade verification.
|
|
# ---------------------------------------------------------------------------
|
|
# Mattermost migrates its schema on boot and refuses to serve the API until it
|
|
# has finished, so a 200 from the ping endpoint carrying the new version is
|
|
# evidence the migration completed.
|
|
#
|
|
# /api/v4/system/ping is unauthenticated. The version is NOT in the body — it
|
|
# rides in the X-Version-Id header, as
|
|
# "11.9.1.311276...<hash>.false": build version first, then metadata. The shared
|
|
# comparison reads leading numbers, so it matches the 11.9 tag against the
|
|
# 11.9.1 build without needing to know that layout.
|
|
|
|
# mattermost_upgrade_verify <app> <expected-tag> <deadline-epoch>
|
|
mattermost_upgrade_verify() {
|
|
updaterVerifyHttpVersion "$1" "$2" "$3" 8065 \
|
|
"/api/v4/system/ping" "header:X-Version-Id"
|
|
}
|