4 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
cc-ci	de658cf40a	AGENTS.md: ship work as PRs, self-merge, operator reviews retrospectively ... Operator policy (2026-08-11), matching cc-ci-orchestrator. Branch, PR, merge once verified, operator reviews after. The PR is not a gate - it is how the work stays legible - so the description carries what changed, why, and the evidence. Recipe repos are explicitly excluded: created and verified, never agent-merged.	2026-08-11 19:09:12 +00:00
cc-ci	4bc92c44eb	style(plausible): ruff format the rewritten event-tracking fixture ... Self-inflicted: the rewrite in eecc4aa left the file unformatted, which the push lint gate flags. Formatting only - no behaviour change. (Note for the operator: the gate is red on main for unrelated reasons - 90 other files also fail ruff format, and tests/unit/test_f211_sso_skip.py fails ruff check C420. Neither is touched here; both predate this branch.)	2026-08-11 14:58:51 +00:00
cc-ci	eecc4aaa51	test(plausible): provision the site through the app, not SQL; add tests/STYLE.md ... The first cut of this fix added a team INSERT next to the existing sites INSERT. That fixed the symptom and kept the cause: a fixture that knows the apps table layout breaks whenever the app changes it, which is exactly what happened here. _register_site now calls Plausible.Sites.create/2 through the app release console, so the app provisions whatever its data model currently requires - including the team it introduced in v3. Verified against BOTH versions on cc-ci: the identical expression works on v2.0.0, which has no teams table at all, and on v3.2.1. No version gate is needed because the fixture no longer depends on the schema. The HTTP provisioning API (POST /api/v1/sites) would have been first choice, but it is gated behind a paid plan and answers :upgrade_required on CE. That is recorded in the code so the next person does not re-derive it. tests/STYLE.md writes the rule down, along with the others this failure exercised: gate on version rather than supporting both schemas (old-version tests can just be deleted - the older version is only exercised through the upgrade tier); correct the fixture or the wait but never the assertion; assert stored state rather than a 202 ack; size waits from the recipes declared readiness; and read the apps own telemetry before deciding a test is stale. Full cold suite against the recipe PR head: level 5 of 5, GREEN.	2026-08-11 14:50:41 +00:00
cc-ci	eb1d6d9161	fix(plausible): register a team so v3 ingests events; widen post-restore health wait ... plausible v3 (community-edition) only ingests events for a site that belongs to a TEAM. The custom tier registered a site row and nothing else, which was enough for v2 — under v3 the POST still acks 202 and the row still exists in postgres, but every event is discarded. ClickHouse records the reason itself in ingest_counters as dropped_not_found, and events_v2 stays empty, so it presents as a silent ingestion stall. Verified on cc-ci against v3.2.1: identical site row with no team -> dropped_not_found and 0 rows; with a team linked -> buffered and the rows land. _register_site now provisions a team and links the site, guarded on the schema actually having teams so it stays a no-op on v2 (the upgrade tier deploys the older base first). Separately, the custom health check waited 60s for /api/health. That tier runs after backup/restore, which disrupts postgres under the app and restarts it, and v3 boots through sleep 10 + createdb + migrate + cache warmers before health flips to 200. Widened to 300s, still far inside the recipe HTTP_TIMEOUT of 1200. The assertion is unchanged: a hard 200 from the real readiness endpoint. Neither change weakens a test - the event tests still require the row to arrive in ClickHouse and match what was sent.	2026-08-11 05:18:18 +00:00