Add docker attestation

[j9ac9k]

Make use of the docker attestation capability when generating images.

Furthermore, use ARM64 GHA runners for generating ARM64 images, which is significantly faster.

What does this PR do?

Add docker attestation features when creating the docker images. Furthermore, have docker use the ARM linux runners when generating the ARM images.

I did my best to test this on my fork, but a lot of this code has to do with the release process of gdal, which I was not able to test as thoroughly as I would have liked (to ensure the attestation for example is indeed distributed). Any guidance towards things that are incorrect would be greatly appreciated.

Furthermore, this PR will make it such that docker buildx is utilized (which is not the default behavior currently).

Happy to explain any of the other changes.

What are related issues/pull requests?

None

Tasklist

• AI (Copilot or something similar) supported my development of this PR
• Make sure code is correctly formatted (cf pre-commit configuration)
• Add test case(s)
• Add documentation
• Updated Python API documentation (swig/include/python/docs/)
• Review
• Adjust for comments
• All CI builds and checks have passed
• ADD YOUR TASKS HERE

Environment

Github Actions (CI).

[rouault]

Add docker attestation features when creating the docker images

I'd note we currently don't publish Docker images through github action. This is only used for now to test pull requests that modify the Dockerfile recipe. So I'm no sure if attestation will bring any benefit right now, but that's a step in the right direction.
There would probably be 2 steps to progress:

• one to publish Docker images of master regularly (every push to master would likely be overkill, but maybe daily)
• and fully automate on tag creation (we'd need to specify somewhere the PROJ version)

One of the difficulty currently is the build process time, in particular for Alpine arm64 images that don't have a x86_64 cross compiler for arm64. But I didn't realize that github was providing ubuntu 24.04 arm64 images. That's a game changer. So ultimately we'd need to have a x86_64 job producing the x86_64 image, a arm64 producing the arm64 image, and another one waiting for the 2 ones to have finished to create the combined image.

[j9ac9k]

So ultimately we'd need to have a x86_64 job producing the x86_64 image, a arm64 producing the arm64 image, and another one waiting for the 2 ones to have finished to create the combined image.

That's what the setup currently is in pdal/pdal, since you can make jobs dependent on each other, you can have the job that generates the manifest run only when the individual images have completed without error.

https://github.com/PDAL/PDAL/blob/master/.github/workflows/docker.yml

I agree that GHA offering linux/arm64 platforms is a game changer. When testing runtimes for docker images, I went from ~3 hours to ~20 minutes for the ARM images.

That said, there is no arm64 image I'm aware of of linuxkit/binfmt:v0.8, hence why I need to specify to use the amd64 image regardless of the platform.

I can certainly setup the docker CI to run from master on a daily basis.

EDIT: the docker CI job not pushing to GHCR as part of the release process now makes a lot more sense, here I was pulling my hair out wondering why I couldn't get that working, ...when that wasn't how this was made to work to begin with.

[j9ac9k]

Currently the GHA runs ubuntu small and ubuntu full on both amd64 and arm64, but the alpine images run only on amd64. Looking at the tags on ghcr.io/osgeo/gdal, looks like arm64 images of alpine models are distributed, so I should create those as well I assume?

[rouault]

so I should create those as well I assume?

yes please

(The current images pushed to ghcr.io are built from my own PC. Cooking time: > 12 hours. Most of that spent for the arm64 images for alpine-small and alpine-normal)

[coveralls]

coverage: 71.206% (-0.002%) from 71.208%
when pulling 6b90643 on j9ac9k:add-docker-attestation
into d479e5a on OSGeo:master.

[j9ac9k]

What should the tag naming scheme be here? Especially for the daily builds from master. Also, not sure how proj versions work their way into this, can you elaborate on that?

[rouault]

What should the tag naming scheme be here?

We currently use for master builds:
osgeo/gdal:ubuntu-full-latest (and a osgeo/gdal:latest alias)
osgeo/gdal:ubuntu-small-latest
osgeo/gdal:alpine-small-latest
osgeo/gdal:alpine-normal-latest

For releases:
osgeo/gdal:ubuntu-full-X.Y.Z
osgeo/gdal:ubuntu-small-X.Y.Z
osgeo/gdal:alpine-small-X.Y.Z
osgeo/gdal:alpine-normal-X.Y.Z

Also, not sure how proj versions work their way into this, can you elaborate on that?

For GDAL master builds, the docker/util.sh script defaults to using PROJ master

For GDAL releases, currently I manually specify the latest PROJ version. Example for the current in-cooking GDAL 3.11.4 release: ./docker/build-all.sh --with-multi-arch --release --tag 3.11.4 --gdal v3.11.4 --proj 9.6.1 --platform linux/arm64,linux/amd64 --push. I suspect to automate that we should perhaps use a github repo variable, and mention in the HOWTO-RELEASE document that we need to update it before setting the GDAL tag.

[j9ac9k]

Deleted a previous comment because I couldn't read.

The proprietary-sdks, those should only be included the ubuntu-full-<whatever> images that use amd64, or should I try and build it with arm64 images too?

[rouault]

The proprietary-sdks, those should only be included the ubuntu-full-<whatever> images that use amd64, or should I try and build it with arm64 images too?

they are x64 only (some might be arm64 but we don't bother) and we should not pushed them to ghcr.io given their license. We just test they build