Skip to content

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.

What are the relevant issue numbers?

#27577

Edited by Anthony Juckel

Merge request reports