Support index manifest to push multi-arch container images

[lbcjbb]

PR Checklist

Please check if your PR fulfills the following requirements:

• [x] Tests for the changes have been added (for bug fixes / features)
• [x] Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• [ ] Bugfix
• [x] Feature
• [ ] Code style update (formatting, local variables)
• [x] Refactoring (no functional changes, no api changes)
• [ ] Build related changes
• [ ] CI related changes
• [x] Documentation content changes
• [ ] Other... Please describe:

What is the current behavior?

The rule container_push is able to push a single container to a registry but isn't able to push a multi-arch containers, aka index or fat manifest.

The specification of an index manifest can be found here:

• Docker manifest list
• OCI Image index

Issue Number: #1599

What is the new behavior?

I add a new rule named container_push_index to push a multi-arch containers.

This new rule can be used like that:

load( "@io_bazel_rules_docker//container:container.bzl", "container_push_index")

container_push_index(
    name = "push_all",
    format = "Docker",
    images = {
        "//:my_image_amd64": "linux/amd64",
        "//:my_image_arm64": "linux/arm64/v8",
        "//:my_image_ppc64le": "linux/ppc64le",
    },
    registry = "localhost:5000",
    repository = "docker/test",
    tag = "{VERSION}",
)

Does this PR introduce a breaking change?

• [ ] Yes
• [x] No

The container_push rule is not impacted and still works fine as always.

[lbcjbb]

We could improve this new rule container_push_index to use a transition to avoid to explicitly specify the list of image targets to push, like this:

load( "@io_bazel_rules_docker//container:container.bzl", "container_push_index")

container_push_index(
    name = "push_all",
    format = "Docker",
    image = "//:my_image",
    platforms: [
        "linux/amd64",
        "linux/arm64/v8",
        "linux/ppc64le",
    ],
    registry = "localhost:5000",
    repository = "docker/test",
    tag = "{VERSION}",
)

Where image attribute is a target created by container_image.

But this improvement requires before several modifications as suggested in #2073.

[aw185176]

Regarding using transitions: one benefit of not doing so, and allowing explicitly wiring up multiple images is that it enables non-traditional use cases such as storing things like K8s manifests (or binaries, or WASM artifacts, etc). I am not sure using transitions is worth losing the flexibility for other use cases.

[lbcjbb]

As I said on Slack, we can keep the images attribute to keep the possibility to explicitly give the list of images to push.

We're able to keep the two differents ways:

• The images attribute to explicitly give the list of images to push.
• The image + platforms attributes to use a transition to define the list of images to push.

And:

• images and image will be mutually exclusive.
• platforms will be mandatory if image is given.
• One of these two attributes betwwen image or images must be defined.

[nadavwe]

hey @lbcjbb, this is super useful! Why is that hanging since May? anything holding it back?

[lbcjbb]

Hi. This project needs new maintainers as mentionened in this discussion https://github.com/bazelbuild/rules_docker/discussions/2038

[nadavwe]

oh... but I see @uhthomas and @linzhp volunteered to be maintainers now...

[drewcsillagdd]

So does this actually have maintainers now?

[lbcjbb]

[samruthr]

This is a very useful addition to the rule. How can we get attention to this PR?

[lbcjbb]

I don't know :/

[uhthomas]

I can take a look soon :)

[samruthr]

Hi @uhthomas, just checking in, have you had an opportunity to take a look?

[lbcjbb]

Thank you very much for the review @uhthomas :heart:.

For all comments related to the Go errors 1.13 (the use of %w), it's maybe better to make this change in another pull request, to migrate all the Go code of this repository.

• [X] All this new code is already covered by E2E tests, but I take a look to also add several unit tests. ✅

I also had another topic I want to discuss. How does this fit into transitions? Is this compatible with a single target which could transition to different target platforms?

If I recall, i don't think. But we will be able to easily add this feature.

[loeffel-io]

@uhthomas please 🙏

[Topher-the-Geek]

I forgot: That's with Bazel 6.0.0

[lbcjbb]

@Topher-the-Geek It's now fixed. Sorry for this stupid mistake. You can apply this patch in your test workspace:

diff --git a/WORKSPACE b/WORKSPACE
index 2e1ba82..91b5101 100644
--- a/WORKSPACE
+++ b/WORKSPACE
@@ -17,14 +17,10 @@ load("@bazel_skylib//:workspace.bzl", "bazel_skylib_workspace")
 
 bazel_skylib_workspace()
 
-RULES_DOCKER_VERSION = "c079c0ddad54d34205c0a94fbb7cf9c6e7a6f48b"
+RULES_DOCKER_VERSION = "19d30777c526fe9986e1a19b49324beb34537ce0"
 
 http_archive(
     name = "io_bazel_rules_docker",
-    patch_args = ["-p1"],
-    patches = [
-        "//:pr2087.patch",
-    ],
     strip_prefix = "bazel-rules_docker-%s" % RULES_DOCKER_VERSION,
     type = "zip",
     url = "https://github.com/leboncoin/bazel-rules_docker/archive/%s.zip" % RULES_DOCKER_VERSION,

[Topher-the-Geek]

Thanks for the quick fix @lbcjbb. For me, this is working as advertised. I'm not an owner of this repo tho, so we still need @uhthomas

[tgeng]

What does it take to get this merged? @uhthomas can you give an update?

[lbcjbb]

What does it take to get this merged?

I don't known. Maybe just some time to review, or find new maintainers of this repository (https://github.com/bazelbuild/rules_docker/discussions/2038).