v0.24.2

v0.24.2 - 2026-11-02

Fixed

• Native jobs in an image without /etc/resolv.conf or /etc/hosts (Alpine's, and most of Docker Hub's but Debian's and Ubuntu's) now get the job's resolver and hosts file: a container: job, a Docker action, its Dockerfile's RUN and a service in such an image had no DNS, since the binds were made only over a file the image has. A layer of the job's below every image holds empty files at both paths, so the binds always have a mount point and no layer of the job's keeps one. A root test now checks that the built-in checkout's and an action's fetch resolve through the job's resolver as root and as the runner user with a Zig seed below (razorbill's toolcache job), and a Docker action in an image without a resolver of its own; the services test asks for postgres 18, as its image script now provides.
• The memory gate no longer holds native jobs back for memory they never use: a native job is learned from its own cgroup under its name, apart from the same job on Dagger, and one not learned yet reserves RUNNER_NATIVE_MEM_PER_JOB_MB (256 MB) instead of the engine's 1.5 GB, which held e2e jobs of a few MB on razorbill's native runners for up to 150 s. Each native job's cgroup gets a memory.high from that estimate (twice it, plus 512 MB), so a job that outgrows it is slowed there rather than taking its neighbours' memory; memory.max stays the hard cap. A job a native pool sends to Dagger is learned on the engine, and a Dagger job is no longer taken as running beside a native one.