83c183d985
All checks were successful
continuous-integration/drone/push Build is passing
Gate satisfied — live: with the pin removed, plausible's upgrade tier resolves base 3.0.1+v2.0.0 via the same-version step-back (canonical 3.1.0 == head 3.1.0 → newest-older = 3.0.1, NOT the broken 3.0.0) and passes install+upgrade green (level 5/5). The pin is redundant, so removed everywhere: - meta.py KEYS entry (RecipeMeta field auto-drops; 15→14 keys). - run_recipe_ci.resolve_upgrade_base override branch + docstrings. - tests/unit/test_meta.py (count 15→14, dropped None-assert), test_upgrade_base.py (override test). - docs/recipe-customization.md (regenerated table + mentions), docs/testing.md. - tests/plausible/recipe_meta.py (pin removed), tests/bluesky-pds (re-enable note → dynamic base). 294 unit tests pass; lint clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
28 lines
1.7 KiB
Python
28 lines
1.7 KiB
Python
# Per-recipe harness config for bluesky-pds (Phase 2 Q4.3 — TLS-passthrough atproto PDS).
|
|
# The recipe routes via Traefik with TLS termination at cc-ci (the wildcard cert covers the
|
|
# bare DOMAIN; the gateway TLS-passthroughs the wildcard zone). atproto PDS exposes XRPC
|
|
# endpoints under /xrpc/* for the public protocol.
|
|
HEALTH_PATH = "/xrpc/_health" # PDS health endpoint; returns {"version": ...} on success
|
|
HEALTH_OK = (200,)
|
|
DEPLOY_TIMEOUT = 600
|
|
HTTP_TIMEOUT = 600
|
|
|
|
# UPGRADE rung: published versions exist (0.1.1+v0.4, 0.2.0+v0.4) but BOTH pin the moving image
|
|
# tag ghcr.io/bluesky-social/pds:0.4, which upstream republished with main-branch builds
|
|
# (@atproto/pds 0.5.1, Node 24, /app/index.ts — no index.js), so NO published version can deploy
|
|
# as an upgrade base anymore: the base crash-loops MODULE_NOT_FOUND before the PR head is ever
|
|
# exercised (phase bsky root cause; cc-ci-plan/upstream/bluesky-pds.md). Declared intentional
|
|
# until a fixed exact-pinned version (0.3.0+v0.4.219, mirror PR #2) is merged AND published —
|
|
# then DROP this EXPECTED_NA and the upgrade rung resolves its base DYNAMICALLY (phase prevb:
|
|
# last-green warm canonical → same-version step-back → main tip), no explicit pin needed
|
|
# (UPGRADE_BASE_VERSION was removed in phase canon §2.G).
|
|
EXPECTED_NA = {
|
|
"upgrade": "no deployable upgrade base: every published version pins the moving tag "
|
|
"pds:0.4, which upstream republished with incompatible main builds (index.js removed) — "
|
|
"drop this once a fixed version is published post-merge (dynamic base then resolves it)",
|
|
}
|
|
|
|
# canon §2.B: enroll as a DATA-WARM canonical (all recipes enrolled — operator 2026-06-17).
|
|
# The weekly sweep promotes this recipe's canonical to its latest green RELEASE TAG.
|
|
WARM_CANONICAL = True
|