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
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:
parent
faaf0862bf
commit
150fd3878c
@ -46,9 +46,30 @@ jobs:
|
||||
echo "${{ secrets.REGISTRY_TOKEN }}" \
|
||||
| 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
|
||||
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
|
||||
run: |
|
||||
for tag in $(echo "${{ steps.meta.outputs.tags }}" | tr ' ' '\n' | grep -v '^-t$'); do
|
||||
|
||||
@ -24,8 +24,13 @@ RUN npm ci --no-audit --no-fund && npm cache clean --force
|
||||
# Prisma-CLI – isolierte Installation samt transitiver Abhängigkeiten, damit
|
||||
# `migrate deploy` beim Start läuft. Das Standalone-Bundle enthält nur, was die
|
||||
# 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
|
||||
RUN npm init -y > /dev/null \
|
||||
&& npm install --omit=dev --no-audit --no-fund prisma@6.16.0 \
|
||||
|
||||
Loading…
Reference in New Issue
Block a user