gitea
cf24c4d473
Testy / Testy warstwy logicznej (silnik) (pull_request) Successful in 10m22s
Testy / Testy warstwy prezentacji (dostęp do baz) (pull_request) Successful in 9m30s
Testy / Testy warstwy bazodanowej (ochrona baz) (pull_request) Successful in 9m25s
Testy / Testy astrodemo (pull_request) Successful in 9m25s
Testy / Build obrazu silnika B (swisseph) (pull_request) Successful in 7s
Testy / Kontrola składni wszystkich warstw (pull_request) Successful in 4s
build-render / build (push) Successful in 2m39s
build / build (push) Successful in 10s
Testy / Testy warstwy logicznej (silnik) (push) Successful in 10m20s
Testy / Testy warstwy prezentacji (dostęp do baz) (push) Successful in 9m29s
Testy / Testy warstwy bazodanowej (ochrona baz) (push) Successful in 9m25s
Testy / Testy astrodemo (push) Successful in 9m25s
Testy / Build obrazu silnika B (swisseph) (push) Successful in 7s
Testy / Kontrola składni wszystkich warstw (push) Successful in 4s
Rejestr obrazów rósł, bo `build.yaml` budował CZTERY obrazy przy każdym pushu do mastera, niezależnie od tego, co się zmieniło. Zmiana w samej prezentacji dawała nowe wersje data, logic i astrodemo — identyczne co do zawartości, różniące się wyłącznie tagiem. Render i silnik B miały filtry ścieżek od początku (build-render.yaml, build-swisseph.yaml) i budują się tylko przy własnych zmianach. Ta zmiana przenosi tę samą zasadę do głównego pipeline'u, licząc różnicę wobec poprzedniego commita. Kontekstem budowania każdego obrazu jest wyłącznie `./services/<nazwa>`, więc porównanie ścieżek jest dokładne, a nie przybliżone. Sprawdzone na ośmiu ostatnich commitach mastera: dwa refaktory prezentacji dają sam `presentation`, poprawka Dockerfile'a astrodemo daje samo `astrodemo`, a commit ruszający link_crypto w pięciu usługach — komplet. Bez porównania (pierwszy commit, przepisana historia) budujemy wszystko: lepiej zbudować za dużo niż wypuścić obraz ze starym kodem pod nowym tagiem. SKUTEK UBOCZNY DO ŚWIADOMOŚCI: tagi w kustomization mogą się teraz rozjechać między usługami, bo nie każda dostaje nową wersję z każdego commita. Tak ma być — image-updater śledzi każdy obraz osobno i przypina to, co istnieje. ZABEZPIECZENIE PRZED CICHYM POMINIĘCIEM. Usługa, której nie ma na żadnej liście, nigdy się nie zbuduje i nikt tego nie zauważy: brak obrazu wygląda potem na problem z rejestrem albo z siecią. Ten sam mechanizm kosztował nas już raz, przy liście obserwowanych obrazów w image-updaterze. Pętla po `services/*/` zatrzymuje budowanie i mówi wprost, co dopisać. Sprawdzone także od strony negatywnej — podstawiony katalog nowej usługi kończy przebieg kodem 1. SPRZĄTANIE NA RUNNERZE, w build.yaml i w build-render.yaml, z `if: always()` — bo to po NIEUDANYM budowaniu zostaje najwięcej śmieci, a kolejny przebieg zaczyna od mniejszego zapasu miejsca niż poprzedni. Tak zatkał się dysk przy renderze z TeX Live. Filtr `until=168h` zostawia tydzień, więc warstwy bazowe i cache przeżywają i build nie zaczyna od zera. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
46 lines
1.9 KiB
YAML
46 lines
1.9 KiB
YAML
name: build-render
|
|
|
|
# Osobny pipeline dla uslugi render (raport PDF, PRE-24) — celowo ODDZIELONY od
|
|
# glownego build.yaml (data/logic/presentation). Obraz dzwiga TeX Live (setki MB),
|
|
# wiec budowanie go przy KAZDYM pushu do mastera spowalnialoby kazdy deploy — a to
|
|
# wlasnie ta izolacja mial usunac (patrz services/render/app/main.py, LOG-27).
|
|
# Buduje sie tylko, gdy zmienia sie sama usluga.
|
|
#
|
|
# Obraz konsumuje astrololo/render.yaml w repo `deploy`.
|
|
on:
|
|
push:
|
|
branches: [master]
|
|
paths:
|
|
- 'services/render/**'
|
|
- '.gitea/workflows/build-render.yaml'
|
|
workflow_dispatch: {} # reczne odpalenie (bootstrap pierwszego obrazu)
|
|
|
|
jobs:
|
|
build:
|
|
runs-on: ubuntu-latest
|
|
steps:
|
|
- uses: actions/checkout@v4
|
|
- name: Login
|
|
run: echo "${{ secrets.REGISTRY_TOKEN }}" | docker login gitea.czernobog.pl -u gitea --password-stdin
|
|
- name: Build & push render (TeX Live — pierwszy build trwa dluzej)
|
|
run: |
|
|
TAG=${GITHUB_SHA::8}
|
|
IMG=gitea.czernobog.pl/gitea/astrololo-render
|
|
# Dockerfile sprawdza obecnosc xelatex + rsvg-convert przy budowie, wiec
|
|
# build jest zarazem testem, ze obraz ma komplet narzedzi.
|
|
docker build -t $IMG:$TAG -t $IMG:latest ./services/render
|
|
docker push $IMG:$TAG
|
|
docker push $IMG:latest
|
|
echo "Zbudowano i wypchnieto: $IMG:$TAG (+ latest)"
|
|
|
|
# Sprzątanie ZAWSZE, także po nieudanym budowaniu. Ten obraz dźwiga TeX Live
|
|
# i to właśnie na nim runner zatkał się kiedyś na „no space left on device" —
|
|
# a po nieudanym buildzie zostaje najwięcej śmieci.
|
|
- name: Sprzątanie po budowaniu
|
|
if: always()
|
|
run: |
|
|
docker system df || true
|
|
docker system prune -af --filter "until=168h" || true
|
|
docker builder prune -f --filter "until=168h" || true
|
|
docker system df || true
|