Rust
notatki (01)
Rust, Docker i problem z cache'owaniem warstw na GHA
Ostatnio dłubię sobie własny vibe-designed rewrite aplikacji todo w Ruscie1. Przy okazji zacząłem szukać sensownej ścieżki do optymalizowania budowania obrazów Dockerowych na GitHub Actions.
Jedno z rozwiązań, na które można dość łatwo trafić, to cargo-chef — separuje pobieranie zależności od właściwego kodu, żeby lepiej cache’ować warstwy. Problem w tym, że jest projektowany pod prostsze aplikacje z jednym lib.rs. W workspace z większą liczbą crate’ów nie cache’uje tego co trzeba i przy każdym pushu i tak kompilujesz wszystko od nowa.
Dwa podejścia które próbowałem: buildkit cache dance2 — trochę przyspiesza, ale nie cache’uje rewelacyjnie i dorzuca własny narzut czasowy3 — oraz swatinem/rust-cache, który na GHA sprawdza się fajnie przy cache’owaniu binarek, ale deployment Kartoteki jako obrazu Dockerowego na Coolify tę akcję wyklucza.
Z researchu wyszło mi, że warto sprawdzić sccache — zrobiłem podejście, ale Hetzner S3 odpada4. Stąd Cloudflare R2 w free tierze jako potencjalna alternatywa5.
Na razie tymczasowo parkuję przy cache dance. Nie jest wykluczone, że pójdę w stronę własnego runnera z lokalnym cache — tylko na trochę większym serwerze.
Footnotes
-
Kartoteka — gdzieś pomiędzy Todoistem, Jirą, Amazing Marvin i Togglem. Klasyczny scope creep. ↩
-
W przypadku Kartoteki dochodzi jeszcze kwestia egzotycznego stacku w postaci Leptosa — razem z plikiem serwera trzeba też deployować zbudowany frontend/wasm. ↩
-
Hetzner S3 rozlicza storage w pakietach po 1 TB — jak na jeden niewinny backup i artefakty do cache to trochę astronomiczne. ↩
-
Tak, wiem — sugerowanie żebym wracał do Cloudflare, kiedy od dwóch tygodni przepisuję MCP z Cloudflare Workera na axum/rmcp żeby zejść z ekosystemu Cloudflare, mhm. ↩