Skip to content

Adding manifest generation/publish via magefiles

Anthony Juckel requested to merge gitlab-community/gitlab-runner:ajuckel/add-manifest-tool-mage-take2 into main

What does this MR do?

This MR packages up the various architecture-specific helper 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. For now, only packages up linux variants. Once the approach is acceptable for linux, similar work can be done to package the windows variants.

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?

The testing I've done so far has been setting up a local environment so I can execute mage images:releaseHelper alpine3.19 alpine3.19 targeting a container registry I control. Once the build is complete, inspecting the resulting manifests to make sure they're in line with expectations. Specifically:

  1. Inspecting the out/helper-images/spec-alpine3.19-*.yml files. These are the files used for publishing the manifests, so validating the list and component images as well as the platform parameters was done.
  2. Inspect the output from e.g. manifest-tool inspect ${CI_REGISTRY_IMAGE}/${HELPER_IMAGE_NAME}:alpine3.19-bleeding to verify the digests for the list components match the expected architecture-specific images.
  3. The next step of the testing process would be to actually run this build as part of CI and verify everything runs as expected. There's certainly a chance that I've missed some of the various combinations of helper images, so verifying all (linux) combinations are supported as expected is work that is yet to be done.

What are the relevant issue numbers?

#27577 Additionally, this work represents a second iteration of the earlier MR !4116 (closed).

Merge request reports