recipe-maintainers/cc-ci
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

journal(redfix): M2 prep — bluesky fix refinement (unique internal alias, not service rename)
Some checks failed
continuous-integration/drone/push Build is failing
Details

Browse Source
This commit is contained in:
autonomic-bot
2026-06-18 00:25:57 +00:00
parent 4777ba8edc
commit 65fe47feea
1 changed files with 11 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
machine-docs/JOURNAL-redfix.md
View File

@ -244,3 +244,14 @@ structurally in code.
Node clean: warm-gitea idle@3.5.3 (volumes retained), orphaned warm-bluesky removed, only live
warm-keycloak up (healthy 200). Claiming M1; will start M2 fix design while awaiting the Adversary
verdict (keep an unblocked item in hand).
## 2026-06-18T00:25Z — M2 prep (gated on M1 PASS): bluesky fix refinement
While parked at the M1 gate (no node deploys — Adversary cold-verifying), refined the bluesky fix:
cc-ci's bluesky tests probe via HTTP (/xrpc/_health), but the GENERIC harness defaults to
`service="app"` (deployed_identity/_app_container). So RENAMING the recipe's `app` service → `pds`
could break generic harness assumptions. Cleaner fix: keep the service named `app` but give it a
UNIQUE network ALIAS on the internal net (e.g. `aliases: [pds-internal]`) and point caddy at
`pds-internal:3000` (reverse_proxy + on_demand_tls ask). A unique alias has no collision on the shared
proxy (only the bare `app` alias collides), and the service name stays `app` → zero cc-ci-side
breakage. Will validate this exact approach in M2 after M1 PASS.