Our build copies uv and uvx from the official Astral image with `COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /bin/`. This worked for about ten days without any changes to our configuration, but after newer uv releases the Docker build began failing with `exec: "/bin/sh": stat /bin/sh: no such file or directory`. The final image is based on `python:3.12-slim`, so I suspect the `latest` tag moved to a different image variant or version. Is there a way to determine which uv version or image digest `latest` referenced before the failure so I can pin that known-working image?
3 Answers
This is a good example of why floating tags are risky in production builds. Pin the image by digest, such as `ghcr.io/astral-sh/uv@sha256:...`, or at least use a specific uv version tag. You may need to inspect the registry or repository history to find the digest from the last successful build.
The exact previous version depends on when the successful image was built. Check the uv image tags and registry history for the version or digest published immediately before that date, then use that immutable reference instead of `latest`. A digest is the safest option because it identifies the exact image contents.
The old image may not still be available in a local Docker cache, so rebuilding with the same command will not necessarily reproduce it. Look for the successful build date in your CI logs or image metadata, match it to a published uv tag or digest, and test that exact reference against the newer image.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures