Build-Spitzenbedarf halbieren und Platz im Log sichtbar machen
All checks were successful
Container-Image bauen und veröffentlichen / build-and-push (push) Successful in 2m22s

Der Workflow bricht weiter mit ENOSPC ab, jetzt in beiden npm-Stufen
gleichzeitig nach 8,2 Sekunden - der Datentraeger ist praktisch voll.

- prisma-cli baut auf deps statt auf base auf. Damit laufen die beiden
  npm-Installationen nacheinander statt parallel, was den gleichzeitigen
  Platzbedarf halbiert. Die deps-Schicht liegt ohnehin vor.
- Der Workflow protokolliert vor dem Bauen Belegung, Inodes und
  docker system df. ENOSPC heisst auch "keine Inodes frei", was df -h
  nicht zeigt - beim naechsten Fehlschlag stehen die Zahlen im Log.
- Ungenutzter Build-Cache aelter als 24h wird vor dem Bauen freigegeben.
  Jeder abgebrochene Versuch hinterlaesst sonst Schichten und macht es
  beim naechsten Mal enger. Betrifft nur Cache, keine Images, Volumes
  oder Container.

Geprueft: Image baut mit serialisierten Stufen, Container startet,
Migrationen laufen, Healthcheck gruen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Weapie 2026-09-08 12:09:55 +02:00
parent faaf0862bf
commit 150fd3878c
2 changed files with 27 additions and 1 deletions

View File

@ -46,9 +46,30 @@ jobs:
echo "${{ secrets.REGISTRY_TOKEN }}" \ echo "${{ secrets.REGISTRY_TOKEN }}" \
| docker login "${REGISTRY}" -u "${{ gitea.actor }}" --password-stdin | docker login "${REGISTRY}" -u "${{ gitea.actor }}" --password-stdin
# Der Build ist mehrfach mit ENOSPC abgebrochen. Damit im Fehlerfall die
# Zahlen im Log stehen: Plattenplatz UND Inodes – ENOSPC bedeutet auch
# "keine Inodes mehr frei", was `df -h` nicht zeigt.
- name: Plattenplatz vor dem Bauen
run: |
echo "── Belegung ──"; df -h /var/lib/docker / 2>/dev/null || df -h
echo "── Inodes ──"; df -i /var/lib/docker / 2>/dev/null || df -i
echo "── Docker ──"; docker system df
# Jeder abgebrochene Build lässt seine Schichten im Cache zurück; ohne
# Aufräumen wird es mit jedem Versuch enger. Entfernt wird ausschließlich
# ungenutzter Build-Cache – keine Images, keine Volumes, keine Container.
- name: Ungenutzten Build-Cache freigeben
run: |
docker builder prune --force --filter until=24h || true
echo "── Docker nach dem Aufräumen ──"; docker system df
- name: Image bauen - name: Image bauen
run: docker build ${{ steps.meta.outputs.tags }} . run: docker build ${{ steps.meta.outputs.tags }} .
- name: Plattenplatz nach dem Bauen
if: always()
run: df -h / 2>/dev/null; docker system df || true
- name: Image veröffentlichen - name: Image veröffentlichen
run: | run: |
for tag in $(echo "${{ steps.meta.outputs.tags }}" | tr ' ' '\n' | grep -v '^-t$'); do for tag in $(echo "${{ steps.meta.outputs.tags }}" | tr ' ' '\n' | grep -v '^-t$'); do

View File

@ -24,8 +24,13 @@ RUN npm ci --no-audit --no-fund && npm cache clean --force
# Prisma-CLI – isolierte Installation samt transitiver Abhängigkeiten, damit # Prisma-CLI – isolierte Installation samt transitiver Abhängigkeiten, damit
# `migrate deploy` beim Start läuft. Das Standalone-Bundle enthält nur, was die # `migrate deploy` beim Start läuft. Das Standalone-Bundle enthält nur, was die
# Anwendung selbst importiert, und damit nicht den CLI. # Anwendung selbst importiert, und damit nicht den CLI.
#
# Bewusst FROM deps statt FROM base: Damit wartet diese Stufe auf die
# Abhängigkeiten, statt parallel zu ihnen zu installieren. Das halbiert den
# gleichzeitigen Platzbedarf auf dem Build-Host. Die Schicht von deps liegt
# ohnehin schon vor, kostet hier also nichts zusätzlich.
# --------------------------------------------------------------------------- # ---------------------------------------------------------------------------
FROM base AS prisma-cli FROM deps AS prisma-cli
WORKDIR /prisma-cli WORKDIR /prisma-cli
RUN npm init -y > /dev/null \ RUN npm init -y > /dev/null \
&& npm install --omit=dev --no-audit --no-fund prisma@6.16.0 \ && npm install --omit=dev --no-audit --no-fund prisma@6.16.0 \