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>
97 lines
4.2 KiB
YAML
97 lines
4.2 KiB
YAML
name: build
|
|
|
|
# Buduje obrazy usług, które dzielą warstwę logiczną i łącze: data, logic,
|
|
# presentation, astrodemo. Render i silnik B mają własne pipeline'y, bo są ciężkie
|
|
# i rzadko się zmieniają (build-render.yaml, build-swisseph.yaml).
|
|
on:
|
|
push:
|
|
branches: [master]
|
|
|
|
jobs:
|
|
build:
|
|
runs-on: ubuntu-latest
|
|
steps:
|
|
- uses: actions/checkout@v4
|
|
with:
|
|
# Dwa commity, bo porównujemy z poprzednim. Domyślny płytki klon ma
|
|
# jeden i `HEAD^` w nim nie istnieje.
|
|
fetch-depth: 2
|
|
|
|
- name: Login
|
|
run: echo "${{ secrets.REGISTRY_TOKEN }}" | docker login gitea.czernobog.pl -u gitea --password-stdin
|
|
|
|
- name: Build & push (tylko usługi, które się zmieniły)
|
|
run: |
|
|
set -eu
|
|
TAG=${GITHUB_SHA::8}
|
|
USLUGI="data logic presentation astrodemo"
|
|
# Usługi z własnym pipeline'em — celowo poza tą pętlą.
|
|
OSOBNE="render engine-swisseph"
|
|
|
|
# Usługa, której nie ma na żadnej z list, nigdy się nie zbuduje i NIKT
|
|
# tego nie zauważy: brak obrazu wygląda potem na problem z rejestrem.
|
|
# Ten sam mechanizm już nas kosztował przy liście obserwowanych obrazów
|
|
# w image-updaterze. Lepiej zatrzymać budowanie i powiedzieć wprost.
|
|
for KATALOG in services/*/; do
|
|
NAZWA=$(basename "$KATALOG")
|
|
case " $USLUGI $OSOBNE " in
|
|
*" $NAZWA "*) ;;
|
|
*) echo "BŁĄD: usługa '$NAZWA' nie jest na żadnej liście budowania."
|
|
echo "Dopisz ją do USLUGI w tym pliku albo daj jej własny workflow"
|
|
echo "(jak render i engine-swisseph), zależnie od tego, czy ma"
|
|
echo "powstawać z każdego commita produktu."
|
|
exit 1 ;;
|
|
esac
|
|
done
|
|
|
|
# Kontekstem budowania każdego obrazu jest WYŁĄCZNIE ./services/<nazwa>,
|
|
# więc zmiana poza tym katalogiem nie może wpłynąć na jego zawartość.
|
|
# Dzięki temu porównanie ścieżek jest dokładne, a nie przybliżone.
|
|
if POPRZEDNI=$(git rev-parse --verify HEAD^ 2>/dev/null); then
|
|
ZMIENIONE=$(git diff --name-only "$POPRZEDNI" HEAD)
|
|
else
|
|
# Pierwszy commit albo przepisana historia — nie ma z czym porównać,
|
|
# więc budujemy wszystko. Lepiej zbudować za dużo niż wypuścić obraz
|
|
# ze starym kodem pod nowym tagiem.
|
|
echo "Brak poprzedniego commita — buduję komplet."
|
|
ZMIENIONE=""
|
|
fi
|
|
|
|
# Zmiana w samym pliku workflow dotyczy wszystkich obrazów naraz.
|
|
if [ -z "$ZMIENIONE" ] || echo "$ZMIENIONE" | grep -q '^\.gitea/workflows/build\.yaml$'; then
|
|
DO_BUDOWY="$USLUGI"
|
|
else
|
|
DO_BUDOWY=""
|
|
for SVC in $USLUGI; do
|
|
if echo "$ZMIENIONE" | grep -q "^services/$SVC/"; then
|
|
DO_BUDOWY="$DO_BUDOWY $SVC"
|
|
fi
|
|
done
|
|
fi
|
|
|
|
if [ -z "$(echo "$DO_BUDOWY" | tr -d ' ')" ]; then
|
|
echo "Żadna z usług się nie zmieniła — nie ma czego budować."
|
|
echo "Wdrożone tagi zostają na poprzednich wersjach, i tak ma być."
|
|
exit 0
|
|
fi
|
|
|
|
echo "Buduję:$DO_BUDOWY (tag $TAG)"
|
|
for SVC in $DO_BUDOWY; do
|
|
docker build -t gitea.czernobog.pl/gitea/astrololo-$SVC:$TAG ./services/$SVC
|
|
docker push gitea.czernobog.pl/gitea/astrololo-$SVC:$TAG
|
|
done
|
|
echo "Tag: $TAG"
|
|
|
|
# Sprzątanie ZAWSZE, także po nieudanym budowaniu — to właśnie po awarii
|
|
# zostaje najwięcej śmieci, a kolejny przebieg zaczyna od mniejszego zapasu
|
|
# miejsca niż poprzedni. Tak zatkał się dysk przy budowaniu rendera.
|
|
- name: Sprzątanie po budowaniu
|
|
if: always()
|
|
run: |
|
|
docker system df || true
|
|
# `until=168h` zostawia tydzień: warstwy bazowe i cache z ostatnich dni
|
|
# przeżywają, więc kolejny build nie zaczyna od zera, a stare znikają.
|
|
docker system prune -af --filter "until=168h" || true
|
|
docker builder prune -f --filter "until=168h" || true
|
|
docker system df || true
|