Fix version number in Docker builds

[omad]

We were getting an unclean git repo inside of the Docker build which is where setuptools_scm determines the version number. This happend because our .dockerignore was excluding some directories that exist in the git repo but aren't required in the docker image.

That's reasonable, but it makes it impossible to determine the version number correctly inside of the docker build.

This change add a docker ARG, and determines the version number in the GitHub Actions workflow before building the image.

Closes #897

---

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

[pjonsson]

This will invalidate the docker cache from this line and onwards.

[pjonsson]

I want good version numbers, but I'm skeptical to the approach in this PR. What is missing for setuptools_scm to behave correctly inside the image, or what things would need to be removed from .dockerignore for it to work?

[omad]

I want good version numbers, but I'm skeptical to the approach in this PR. What is missing for setuptools_scm to behave correctly inside the image, or what things would need to be removed from .dockerignore for it to work?

For setuptools_scm to operate correctly in the build, it needs to have a clean checkout of the tagged/released git repo.

There's a whole bunch of things that are being ignored at the moment that exist in the repo.

This is clearly not quite right, but what would you propose as a better fundamental approach?

I did also consider building a wheel outside of the docker, and then installing that inside.

I'm not at all happy with the current Dockerfile, I really don't like the combined development/deployment approach. If we were to keep it combined, it should be done using --target to specify which variant to build, rather than an ARG.

[pjonsson]

How about switching version numbering scheme (https://setuptools-scm.readthedocs.io/en/latest/extending/#version-number-construction) to no-guess-dev and local_scheme to no-local-version? The changes in #935 makes the page report v3.1.1 if I tag a commit and build a deployment image, and adds a .post0.devN if I add a commit on top of the commit that the tag points to and rebuild the image.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 84.23%. Comparing base (519c7d3) to head (f0e516a).
⚠️ Report is 5 commits behind head on develop.

Additional details and impacted files

@@           Coverage Diff            @@
##           develop     #933   +/-   ##
========================================
  Coverage    84.23%   84.23%           
========================================
  Files           35       35           
  Lines         4199     4199           
  Branches       526      526           
========================================
  Hits          3537     3537           
  Misses         471      471           
  Partials       191      191           

☔ 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]

This should not be required, it's supposed to be handled by line 72.

[pjonsson]

I think we should have something like this earlier in the Makefile:

ifdef NO_UV
VERSION_CMD = git describe --tags | sed 's#\-g#+g#'
else
VERSION_CMD = uvx setuptools-scm
endif

and then use $(VERSION_CMD) inside the parenthesis in the places that now have $$(uvx setuptools-scm). This would make it possible to build the image even for someone who doesn't have uv installed on their machine (me, as one example).