Create manifest lists for gitlab-runner-helper docker images
What does this MR do?
This MR packages up the various architecture-specific images into a manifest list. For example, v16.3.0-ubuntu
would be a list referring to all of the architecture-specific variants of that tag. Similarly, the two windows versions are packaged in to v16.3.0-servercore
and v16.3.0-nanoserver
. The bare version, v16.3.0
would refer to the default alpine version.
Why was this MR needed?
My goal for this PR is to move toward a mutli-arch runner suite where the helper image does not need to be modified at all. Whether the runner is linux/amd64 or linux/arm64/v8, the configured image name would be the same. The only time the helper image would need to be configured is if the user wanted a different OS (I'm not yet planning on including linux and windows in one manifest), or different linux distribution/version (alpine3.13 vs alpine3.15 vs ubuntu).
What's the best way to test this MR?
With the current status, when running make release_helper_docker_images
the appropriate manifest should be produced. If the images aren't being pushed, the manifest-tool yaml manifest should be printed to the log. If images are being pushed, manifest-tool will be used to push that manifest to the normal location. Manual tests could include:
-
Visual inspection of the manifest yaml to verify it matches expectation before it is pushed. -
After the manifest list is pushed, inspecting the manifest list from the repo to verify it matches expectation. -
Attempting to run the manifest list on various architectures to ensure the container of the appropriate architecture is selected.