Multiplatform/arch uv support in Docker

[omad]

The Docker Image here was failing to build for me on an ARM Mac, because it was using a Linux ARM base image with an x64 binary of uv.

Install uv from a distroless docker image instead of downloading the binary directly. This is documented at uv_docker and is an easy way to support multiple platforms/architectures.

---

📚 Documentation preview 📚: https://datacube-explorer--826.org.readthedocs.build/en/826/

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 84.35%. Comparing base (66904a9) to head (e582882).
⚠️ Report is 3 commits behind head on develop.

Additional details and impacted files

@@           Coverage Diff            @@
##           develop     #826   +/-   ##
========================================
  Coverage    84.35%   84.35%           
========================================
  Files           35       35           
  Lines         4244     4244           
  Branches       537      537           
========================================
  Hits          3580     3580           
  Misses         468      468           
  Partials       196      196           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[pjonsson]

The copy should use --link, and there is a later step copying the binaries from /usr/local/bin so the binaries need to go in that directory.

On the security side, the --from doesn't contain a sha256 like the FROM at the top of this file, so if someone manages to switch where 0.8.14 is pointing we could get some bad binaries. Considering uv builds the entire image, we're opening ourselves up quite a lot, and I would rather not do that.

I use Linux/x86-64 so I don't know anything about multi-platform builds, but the third bullet in "Remediation steps" at this link describes how to get the manifest list hash so we can pin that: https://github.com/ossf/scorecard/blob/40576783fda6698350fcbbeaea760ff827433034/docs/checks.md#pinned-dependencies

Edit: and please put a comment above the COPY that describes how to get the sha256 when you have figured out how to do it, otherwise you'll be the one who has to update uv across all ODC repositories forever.

[omad]

Thanks, I didn't know about --link. I'm still not sure exactly what it's for, but the docs say to use it unless you've got symlinks to deal with.

We don't have pinned digests in all our Dockerfiles yet, so I was going to just ignore the pinning issue. But, I've managed to make it work.

You can get the digest for a docker image by running docker buildx imagetools inspect ghcr.io/astral-sh/uv:0.8.15.

Dependabot will update the tag and digest. (It won't add a digest if it's not already there)

[pjonsson]

@omad If you're curious, there's a picture for the difference between with and without --link about a page down at https://www.docker.com/blog/image-rebase-and-improved-remote-cache-support-in-new-buildkit/

And I think this version looks fabulous, especially since Dependabot will deal with updating uv in the Docker image from now on!