All three image build workflows previously hardcoded REGISTRY=codeberg.org
and only pulled USER/PASSWORD from secrets. Switching the URL to come from
the same secrets bag means a registry rotation only needs the
REGISTRY_URL / REGISTRY_USER / REGISTRY_PASSWORD secrets updated, not a
commit to every workflow file.
Both build workflows now push to codeberg.org/gmcintire/<image>
alongside the runtime base. Login URL is the hardcoded env.REGISTRY
rather than secrets.REGISTRY_URL so a stale/wrong URL secret can't
silently push to the wrong registry.
k8s deployment manifests still reference git.mcintire.me images and
need a follow-up bump to codeberg-side tags after the next CI build
lands an image at codeberg.org.
Move the runtime base image from git.mcintire.me/graham/prop-base
to codeberg.org/gmcintire/prop-base. The shared REGISTRY_USER /
REGISTRY_PASSWORD secrets are pointed at Codeberg credentials;
the build-base workflow hardcodes env.REGISTRY=codeberg.org so it
can't accidentally push to a different registry if the URL secret
drifts.
The main app + prop-grid-rs builds still pull this base via the
BASE_IMAGE arg in Dockerfile, now codeberg.org/gmcintire/prop-base:latest.
Adds a Sunday 06:00 UTC schedule trigger to build-base.yaml plus a
CACHE_BUST=<ISO year+week> build-arg keyed off `date -u +%G-W%V`. The
apt RUN steps in Dockerfile.base reference the arg in their command
line so BuildKit's layer hash changes when the week rolls over,
forcing apt-get update + install to re-execute and pull fresh
security updates.
The wgrib2-builder stage doesn't see CACHE_BUST so the ~5-min wgrib2
compile keeps hitting layer cache across weeks; only the apt layers
rebuild. Effective cost of the weekly job: ~2 min for the cdo /
gdal-bin reinstall.
Pre-builds the runtime base (wgrib2 + g2c + cdo + gdal-bin + locale +
runtime apt deps) into git.mcintire.me/graham/prop-base. The base
workflow is path-filtered to fire only on Dockerfile.base /
build-base.yaml changes, so version bumps stay deterministic and
explicit.
Tag convention: `wgrib2-<v>-g2c-<v>-<unixts>` for traceability +
rollback, plus `:latest` for everyday consumption.
This commit only adds the new files — the app Dockerfile + build.yaml
still build wgrib2 from source. A follow-up will swap the app
Dockerfile to FROM prop-base:latest once this image lands in the
registry.
Mirrors the verbose wait-for-docker block from build.yaml so future "failed
to connect to docker" failures print socket permissions, docker-related
env vars, and full `docker info` output instead of a single unhelpful line.
The previous approach (`docker run -v $(pwd)/rust/prop_grid_rs:/src`)
fails under act_runner because the runner container's pwd isn't a path
the host docker daemon can see — clippy installed, then cargo couldn't
find Cargo.toml.
Move the lint + test gate into the Dockerfile builder stage so the
build context ships over the socket the normal way. If clippy warns or
a test regresses, the image build fails and nothing is pushed.
Runs `cargo clippy --all-targets -- -D warnings` + `cargo test` inside
a rust:1.94-trixie container, then builds `rust/prop_grid_rs/Dockerfile`
and pushes three tags: the timestamped `main-<ts>-<sha>`, `latest`, and
a static `main` tag that `k8s/deployment-grid-rs.yaml` pins to.
Path-filtered to `rust/prop_grid_rs/**` so Elixir-only pushes don't
trigger a redundant Rust build.
The host docker socket wasn't mounted consistently across act_runners,
so which runner picked up the push was the difference between a clean
build and "unable to connect to docker." Switch to a dockerd service
pinned to the same bridge network as the job; the CLI now talks to
it over TCP via DOCKER_HOST=tcp://dockerd:2375. Every runner has a
daemon, every time — no more re-runs for the scheduling lottery.
The 30s poll is enough to ride out a slow daemon startup, but not a
runner where the socket isn't mounted at all. Print DOCKER_HOST, the
socket stat, and the verbose `docker info` error on timeout so the
next flaky run tells us whether it's a startup race or a missing
mount.
Forgejo act_runner mounts the host docker socket into the job
container; the daemon sometimes takes a beat to answer, which has
been surfacing as intermittent "unable to connect to docker" failures
on login. Gate the build on a `docker info` poll (up to 30s) so later
steps don't race the socket, and wrap login + buildx push in a 3-try
exponential-backoff (2s/4s/8s) so a transient registry hiccup doesn't
require a manual workflow re-run.
The Dockerfile uses `--mount=type=cache` which requires BuildKit.
The static docker tarball only ships the CLI, so the plugin has to
be installed separately. Also flip the build step to
`docker buildx build --push` so build and push happen in one pass
instead of two (avoids the intermediate local-daemon load).
The runner image's bookworm apt repos have been failing GPG
verification with "At least one invalid signature was encountered"
on every job. Clearing lists and reinstalling debian-archive-keyring
on the host doesn't help because the runner spins up a fresh
container per job. Dodge apt entirely by grabbing the static Docker
27.5.1 client binary from download.docker.com. The binary talks to
the host's /var/run/docker.sock that act_runner mounts into the job
container, which is all we need for build + push.
Docker final stage bakes BUILD_TIMESTAMP into /app/BUILD_TIMESTAMP via
build-arg (only consumed after mix compile, so earlier layer caching is
preserved). Application.build_timestamp/0 reads the file, falls back to
DEPLOY_TIMESTAMP env, then to compile time. Navbar renders a compact
"Deployed Xm ago" with the full UTC time in the tooltip.
setup-buildx-action downloads from GitHub Releases which is slow
and unreliable from the Forgejo runner. Plain docker build/push
works fine since Docker is already on the runner host.
