revert: restore sleep 10 (needed for pgautoupgrade window) #5
trav
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: recipe-maintainers/plausible#5
Reference in New Issue
Block a user
Recipe upgrade.
Commits on top of upstream main:
b5cf2a9chore: drop sleep 10 from app command (align with upstream v3)161fe5efix: bump CLICKHOUSE_USER_CONF_VERSION v2→v3 for root elementad6b93afix: update .env.sample for CE v3.x SMTP requirements and add config versions78124a5chore: upgrade to ghcr.io/plausible/community-edition:v3.2.1Tested green on the cc-ci recipe CI server (full suite, cold, against this PR head). NOT merged — for operator review.
cc @trav @notplants
!testme
🌻 cc-ci —
plausible@ad6b93a1❌ failurefull logs · dashboard
upgrade: plausible v2.0.0 → v3.2.1, clickhouse 23.4 → 24.12to fix: bump CLICKHOUSE_USER_CONF_VERSION v2→v3 for <clickhouse> root element!testme
🌻 cc-ci —
plausible@161fe5e4❌ failurefull logs · dashboard
fix: bump CLICKHOUSE_USER_CONF_VERSION v2→v3 for <clickhouse> root elementto chore: drop sleep 10 from app command (align with upstream v3)!testme
🌻 cc-ci —
plausible@b5cf2a9d❌ failurefull logs · dashboard
chore: drop sleep 10 from app command (align with upstream v3)to revert: restore sleep 10 (needed for pgautoupgrade window)!testme
🌻 cc-ci —
plausible@867ebfaf❌ failurefull logs · dashboard
The upgrade itself is fine — the RED is a stale cc-ci test. Diagnosed on cc-ci against this PR head (
867ebfaf).install,upgrade,backupandrestoreall pass. Only the three custom tests fail, for two reasons that are both in the tests:sitesrow and nothing else, which was enough for v2. Undercommunity-editionv3 a teamless site is dropped —POST /api/eventstill returns 202 and the postgres row still exists, so it looks like a silent ingestion stall. ClickHouse names the reason itself iningest_counters:dropped_not_foundwith 0 rows; link a team and it flips tobufferedand the rows land. Verified both ways on cc-ci.sleep 10→createdb→migrate→ cache warmers first.Test fix: cc-ci#17. With that branch, the full cold suite against this PR head is GREEN, level 5 of 5 — all three previously-failing tests pass. Neither change weakens an assertion: the event tests still require the row to reach ClickHouse and match what was sent, and the health test still requires a hard 200.
Dependent pair:
!testmehere runs the deployed cc-ci tests, so this PR stays RED until cc-ci#17 merges. Merge that first, then re-run!testmehere.One unrelated thing to fix before release:
compose.ymlstill carriescoop-cloud.${STACK_NAME}.version=3.1.0+v2.0.0, which does not match this upgrade.!testme
🌻 cc-ci —
plausible@867ebfaf❌ failure → https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1239(summary card unavailable — see the run for details.) full logs · dashboard
!testme
🌻 cc-ci —
plausible@867ebfaf❌ failure → https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1240(summary card unavailable — see the run for details.) full logs · dashboard
Test fix is merged — but do not read the red
!testmebadge as a plausible failurecc-ci#17 and
cc-ci#18 are merged, so
mainnowcarries the fixed fixture.
This PR's suite passes. Verified by running the harness the same way
!testmedoes — full coldsuite, this PR head (
867ebfaf), from a fresh clone of cc-cimain:All three previously-failing tests pass. That result has now been reproduced three times.
!testmeis separately broken right now, and it is not this recipe. Builds 1239 and 1240 bothreport failure but produce no run artifacts at all — no
results.json, no summary card — so theharness never completed. The last build to produce results was 1235; nothing since 1236 has, which
predates today's test change. Two other CI-side problems are visible on the host and are worth
looking at together:
mainindependently of this work — 91 files failruff formatandtests/unit/test_f211_sso_skip.pyfailsruff checkC420. A 91-file reformat isan operator call, so I have not touched it.
warm-giteacanonical is down (0/1), crash-looping onfailed to save "/etc/gitea/app.ini": read-only file system.I could not read drone's build log to pin the exact cause — it needs a drone token, and the bridge
container that holds one is distroless with no shell. That is the next thing to check.
Still outstanding on this PR before release:
compose.ymlcarriescoop-cloud.${STACK_NAME}.version=3.1.0+v2.0.0, which does not match this upgrade.!testme
🌻 cc-ci —
plausible@867ebfaf✅ passedfull logs · dashboard
!testme
🌻 cc-ci —
plausible@867ebfaf❌ failure → https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1248(summary card unavailable — see the run for details.) full logs · dashboard
!testme
🌻 cc-ci —
plausible@867ebfaf✅ passed → https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1251(summary card unavailable — see the run for details.) full logs · dashboard
These five were added to .env.sample while abra.sh already exported them, so every deployment got a second, divergent copy. That is not just untidy. .env.sample becomes the operator .env at `abra app new`, and a .env is NEVER updated by a recipe upgrade. So the next time a recipe change bumps e.g. CLICKHOUSE_ENTRYPOINT_VERSION in abra.sh, an existing deployment keeps the stale value from its .env: the config CONTENT changes while the swarm config NAME does not, and swarm configs are immutable - FATA failed to update config <stack>_clickhouse_entrypoint_v6: only updates to Labels are allowed which is exactly the failure gitea hit with app_ini_v22. The fleet convention, consistent across gitea/discourse/keycloak/mailu: .env.sample carries SECRET_*_VERSION only (operator-managed secret rotation); config object versions live in abra.sh (recipe-managed - bumping one IS a recipe change). plausible main already followed this; only this branch diverged. abra.sh is unchanged and keeps CLICKHOUSE_USER_CONF_VERSION=v3 - that bump is correct, clickhouse-user-config.xml content genuinely changed.!testme
🌻 cc-ci —
plausible@9e731649❌ failure → https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1252(summary card unavailable — see the run for details.) full logs · dashboard
!testme
🌻 cc-ci —
plausible@9e731649✅ passed → https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1253(summary card unavailable — see the run for details.) full logs · dashboard
Config object versions belong in
abra.shonly — fixedThis branch had added five config-object versions to
.env.samplewhileabra.shalreadyexported them, so every deployment would get a second, divergent copy.
maindoes not do this;only this branch diverged.
That is not just untidy.
.env.samplebecomes the operator's.envatabra app new, and a.envis never updated by a recipe upgrade. The next time a recipe change bumps e.g.
CLICKHOUSE_ENTRYPOINT_VERSIONinabra.sh, an existing deployment keeps the stale value from its.env: the config content changes while the swarm config name does not, and swarm configs areimmutable —
which is exactly the failure gitea hit with
app_ini_v22.The fleet convention is consistent across gitea / discourse / keycloak / mailu:
.env.samplecarriesSECRET_*_VERSIONonly (operator-managed secret rotation); config object versions live inabra.sh(recipe-managed — bumping one is a recipe change).abra.shis untouched and keepsCLICKHOUSE_USER_CONF_VERSION=v3— that bump is correct, sinceclickhouse-user-config.xmlgenuinely changed (<yandex>→<clickhouse>).Also reconciled from upstream
git.coopcloud.tech/coop-cloud/plausiblefirst: still atv2.0.0, sothis PR is genuinely needed and the branch is 0 commits behind mirror
main.Re-verified
!testme✅ passed — build 1253, level 5 of 5 (install, upgrade, backup, restore, custom) at9e731649, i.e. with the config versions resolving solely fromabra.sh.View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.