provide additional Alpine-based Docker image for use in Gitlab CI pipelines

[umesecke]

The published Docker image only contains the executable manifest-tool which is fine for running it locally on my machine. But when trying to use the image in our Gitlab CI pipeline it does not work because Gitlab requires a shell in the image.

Could you provide an additional image based on Alpine as well?

[Starttoaster]

For that matter, this would be useful in any CI tool that runs job scripts inside a container. Which is a lot of them.

I've taken to making my own unofficial manifest-tool images, as have many many other people. This would be an extremely welcome addition for anybody that builds images in CI and would like to add this to their pipeline to merge multiple single-arch image manifests.

[Starttoaster]

For what it's worth, if it saves anybody else a couple minutes, this is my Dockerfile:

FROM golang:alpine AS builder
RUN apk add git && \
    git clone https://github.com/estesp/manifest-tool.git
WORKDIR /go/manifest-tool/v2/cmd/manifest-tool
ARG GOOS
ARG GOARCH
RUN GOOS=$GOOS GOARCH=$GOARCH go build -o /manifest-tool

FROM alpine:3
COPY --from=builder /manifest-tool /usr/local/bin/manifest-tool

Build with the container image builder of your choice, and make sure to pass GOOS and GOARCH on the command line as build args.

Or if you want, you can use my image. It only currently supports linux amd64 and arm64, and it's available at registry.gitlab.com/brandonbutler/images/manifest-tool:latest if anybody wants to use that in the meantime, or else fork and set up your own. https://gitlab.com/brandonbutler/images

A big downside to my image is that it doesn't appropriately tag images based on the version of manifest-tool. Just clones whatever is in the default branch and builds it and throws a :latest tag on top. It's something I'm personally okay with, but I think ideally an official image tagging pattern matches the other existing official images

But I would be greatly interested in not managing my own image with a shell for use in CI. And I'm not interested in just downloading a manifest-tool binary in the middle of my CI scripts because it eats additional CI time and lengthens my feedback loops, and is, in my opinion, a method more prone to breakage than just pulling an image with everything installed.

[estesp]

This seems reasonable; my only concern is whether I will need to handle a more regular respin once there are OS components to handle CVE/fixes over time versus only generating images on this tool's release boundaries. Let me look into it. I could at least have a variant of both the binary-only image and an Alpine based and potentially warn that the Alpine based is effectively as-is, potentially without a regular update cycle unless someone has good ideas for that piece.

[Starttoaster]

potentially without a regular update cycle unless someone has good ideas for that piece.

The way I currently handle this is just scheduled image builder pipelines in CI that pull whatever the current alpine:3 is that moment in time. If this breaks, IMO it's OSS and if somebody complains they're welcome to a PR, right? ;)

If someday an alpine:4 comes out, maybe you update to that if you feel so inclined, or maybe somebody opens an Issue and you tell them they are welcome to submit a PR, citing your mentioned "as-is" clause.

I, for one, would just be psyched to not have to maintain my own multi-arch images for manifest-tool with a shell. :)

[Starttoaster]

If you'd like, I could take a stab at this myself. You've seen my Dockerfile posted above already, which would just need some tweaks since cloning and building off the trunk branch would be unnecessary over here. I'm more familiar with GitLab but have used GitHub Actions. I just haven't actually worked on a PR for this yet because I was curious to see what your response would be to this Issue :)

[estesp]

This is currently available in the just-released v2.0.4:

$ docker run -ti --entrypoint /bin/sh mplatform/manifest-tool:alpine
/ # manifest-tool -v
manifest-tool version 2.0.4 (commit: 0e4d8b32fec16134b7d0b7ea837af25cd10a1ed8)
/ #

[Starttoaster]

Worth noting in addition that to use this specifically in gitlab CI, you will need to override the entrypoint like so:

manifest-tool:
  image:
    name: mplatform/manifest-tool:alpine
    entrypoint: [""]

Just figured I'd add this note for posterity. Thanks again for this Issue and for accepting the PR! Really glad to not have to maintain my own image now 🎉