Skip to content

ci(EYT-126/142): GHCR-Images in CI bauen, Staging-Topologie zieht statt zu bauen - #91

Merged
DYAI2025 merged 6 commits into
masterfrom
feat/eyt-126-ghcr-images
Aug 24, 2026
Merged

ci(EYT-126/142): GHCR-Images in CI bauen, Staging-Topologie zieht statt zu bauen#91
DYAI2025 merged 6 commits into
masterfrom
feat/eyt-126-ghcr-images

Conversation

@DYAI2025

@DYAI2025 DYAI2025 commented Aug 24, 2026

Copy link
Copy Markdown
Owner

Was

Phase 2 des Plans docs/plans/2026-08-23-sprint-6-restarbeit.md — ein ziehbares Deployartefakt, damit der VPS (2,6 GB freier RAM neben sechs fremden Workloads, gemessen 23.08.2026) nicht selbst bauen muss:

  • .github/workflows/release-images.yml (Task 2.1): baut easytree-api und easytree-web auf GitHub-Runnern (linux/amd64), pusht nach GHCR unter Commit-SHA + master-Tag, schreibt Digest in die Step-Summary. Bewusst kein Pflichtcheck und bewusst nicht in ci.yml — beide Branch-Protection-Skripte lesen nur ci.yml und meldeten sonst Drift. GIT_SHA ohne Default, Lowercase-Schritt für den GHCR-Pfad (Owner ist DYAI2025).
  • docker-compose.staging.yml (Task 2.2): identische Topologie wie docker-compose.yml, aber image: statt build:; alle Pflichtvariablen mit :?-Fail-closed, Digest-Pinning vorgesehen. Nur web veröffentlicht einen Port.
  • apps/api/test/deploy-authority.test.ts (Task 2.3): die neue Topologie steht unter demselben Autoritätswächter (CONTAINER_DATEIEN 3→4 samt Längenzusicherung) — ein supabase db push darin würde rot.
  • Scope-Manifest Revision 7 (+ Rationale-Korrektur 24.08.): nimmt genau docker-compose.staging.yml in den Sprint-6-Scope; PO-Entscheidung 23.08.2026.

Evidenz (lokaler Lauf, Worktree, 23./24.08.2026)

  • Gegenmutationen ausgeführt und zurückgenommen: Service-Role-Secret in den Workflow → secret-surface.test.ts rot und nennt release-images.yml:92; supabase db push in den api-Dienst → deploy-authority.test.ts rot mit Datei/Werkzeug/Zeile.
  • Compose-Fail-closed gegengeprüft: ohne Variablen exit=1 mit :?-Meldungen; mit Variablen lösen beide image:-Zeilen auf.
  • Vollgate 24.08.: turbo run lint typecheck test --forceTasks: 22 successful, Cached: 0 cached; Prettier exit 0; PRIL-Scope-Guard exit 0 (33 Dateien); verify-branch-protection.sh0 offen.

Ausdrücklich ungetestet (feuert erst nach Merge)

release-images.yml läuft nur auf push: master / workflow_dispatch. Ob GHCR den GITHUB_TOKEN akzeptiert und steps.push.outputs.digest gefüllt ist, misst erst der erste Lauf nach dem Merge (Plan Task 2.4 Generalprobe).

Keine Migration, keine Schemaänderung, keine Produktionswirkung.

🤖 Generated with Claude Code

Summary by Sourcery

Build deployable container images in CI and have staging pull immutable artifacts instead of building them on the deployment host.

New Features:

  • Add a CI workflow that builds and publishes the API and web images to GHCR for deployment by commit and release tags.
  • Add a staging Compose topology that pulls prebuilt, digest-pinned images instead of building on the target server.

Enhancements:

  • Extend deployment-authority checks to cover the staging Compose configuration and preserve a single migration authority.
  • Require staging image and runtime configuration variables to fail closed when missing.

CI:

  • Run image publishing on master pushes and manual workflow dispatch without adding a required branch-protection check.

Deployment:

  • Enable staging deployments to consume immutable GHCR image digests while exposing only the web service publicly.

Tests:

  • Update deployment-authority test expectations for the additional container configuration.

Chores:

  • Update the Sprint 6 scope manifest to include the staging deployment topology.

BenPerro and others added 6 commits August 23, 2026 20:13
…Sprint-6-Scope

Der PRIL-Scope-Gate wies docker-compose.staging.yml ab (PRIL_POLICY_VIOLATION,
exit_code=3). Die Datei beschreibt die laufende Software und steht deshalb unter
scope.product, dem Praezedenzfall von docker-compose.yml aus Revision 5 folgend.

Genau ein Pfad, kein Platzhalter: eine kuenftige dritte Topologie soll wieder eine
bewusste Entscheidung brauchen.

Die Nummer ist 7 und nicht 8, obwohl auf Revision 6 aufgesetzt wird: der Guard
erzwingt lueckenlose Nummern ("provenance revision must be contiguous; expected 7").
Die gleichnamige uncommittete Revision 7 im Haupt-Worktree bleibt unangetastet und
wird beim Committen auf 8 umnummeriert; die Begruendung im Manifest sagt das.
…oritaetswaechter

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…mern- und Reihenfolgeaussage

Der committete Text begann mit 'Revision 8 nimmt ...', obwohl der Eintrag
die 7 traegt, und behauptete, die Manifestreihenfolge sei die
Entscheidungsreihenfolge — widerlegt durch die eigenen Zeitstempel
(01:51 vor 20:36 am 23.08.2026). Belegt ist allein die
Festschreibungsreihenfolge auf der kanonischen Historie. Nur Rationale-Text;
der scope_digest hasht ausschliesslich .scope und bleibt unveraendert.
Prettier exit 0, PRIL scope guard exit 0 (33 Dateien).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@DYAI2025
DYAI2025 merged commit f17a157 into master Aug 24, 2026
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants