chore(deps): bump the CI image to Elixir 1.20.4 / OTP 29.0.6 #9
Loading…
Reference in a new issue
No description provided.
Delete branch "chore/otp-29-0-6-bump"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
OTP 29.0.5 is flagged for the eleven high CVEs of the 2026-09-01 OTP security release — CVE-2026-75538 (signed length overflow in the inet TCP driver, reachable from an unauthenticated peer) and the httpd/inets set among them — and Elixir 1.20.3 for CVE-2026-75758.
Dockerfile.ci:ELIXIR_IMAGE→hexpm/elixir:1.20.4-erlang-29.0.6-debian-trixie-20260824-slimDockerfile.base:DEBIAN_VERSIONtrixie-20260518→trixie-20260824, so the wgrib2 build stage stops shipping a four-month-old baseflake.lock: nixpkgs 2026-08-26 → 2026-09-05, whosebeam29Packagesis OTP 29.0.6 / Elixir 1.20.4Not covered here
The application image's builder is
git.mcintire.me/graham/elixir-base:latest(Dockerfile:7,Dockerfile.base:16), which this repo does not build. Its Elixir/OTP pin has to move in that repo for the release image to pick up 29.0.6 — this change covers the CI image and the base's Debian layer only.Verification
In the updated shell: Elixir 1.20.4 on OTP 29,
mix compile --warnings-as-errorsclean,mix hex.auditclean,mix test4899 passed / 12 failed — all 12 inWgrib2Test, pre-existing and environmental: the Nix shell carries neitherwgrib2norcdo(they live in prop-base), so those cannot pass locally on any toolchain.Clean. No findings.
Dockerfile.ci: tag verified live on Docker Hub (pushed 2026-09-01, amd64+arm64), andbuild.yamlbuilds the CI image with noELIXIR_IMAGEoverride — the bump is what the test job actually runs.Dockerfile.base:DEBIAN_VERSIONonly feeds thewgrib2-builderstage and stays inside trixie (same glibc symbol set — no linkage drift into the runtime image); wgrib2/g2c pins untouched.flake.lock: dev-shell only — no CI workflow evaluates the flake (all docker).graham/elixir-basere-locks nixpkgs and pusheslatestnightly, and merging this PR triggers thebuild-base.yamlrebuild ofprop-base:latest— so the deployed image follows 29.0.6 without a manual pin move.