Distribute as Docker Image

[mircea-pavel-anton]

I think it would be helpful to also distribute this tool as a multi-platform Docker image.

My main usecase for this is using that image as a makeshift build-step when building out larger images. Like this, for example.

Since we're already using goreleaser to create the release artifacts, it would be a fairly simple change to instruct it to also build and push the docker images as well.
Something like this should do the trick, with an extra docker login step in the goreleaser workflow.

If there is interest in this, I can put together a PR with the proposed changes.

[andreynering]

Hi interested people.

I see @maehldom opened a PR #1868 with a possible approach. I'm not sure if we're going to use that approach because Goreleaser also support Docker in theory. We'll see which is better...

I'd just like to say that I created an organization on Docker Hub and applied to their OSS plan, so we're one step closer to make this happen.

• Organization: https://hub.docker.com/orgs/taskfile/members
• Placeholder repository: https://hub.docker.com/r/taskfile/task

[mircea-pavel-anton]

@andreynering any particular reason for choosing DockerHub instead of pushing to ghcr.io and linking the package to this repository?

[andreynering]

@mircea-pavel-anton I just assumed Docker Hub was the default option and didn't think about alternatives.

Are you aware of any advantages and disadvantages of each platform that I should be aware of?

[mircea-pavel-anton]

@andreynering I generally prefer the GitHub Container Registry (ghcr.io) over DockerHub.

For one, DockerHub has more aggresive rate-limiting for pulling images so it can end up being problematic for certain CI/cD workflow scenarios.

Also, I personally like using GHCR because it allows me to link one or more packages directly to the repo and also show the README of the repo as a description of the image.

You can check out this repo as an example: https://github.com/mirceanton/external-dns-provider-mikrotik
It also has the goreleaser docker configuration.

[mircea-pavel-anton]

Also, left some thoughts on #1868 though I think I'd much rather go with the goreleaser approach

[andreynering]

Thanks @mircea-pavel-anton. GHCR does look simpler, indeed. I'll think about it.

[mircea-pavel-anton]

@andreynering I threw together this PoC if you are interested in what this would all look like: #1875

It's not yet done, but it should give you a rough idea. Left some notes on the PR

[trulede]

What is the point of this exactly? To distribute task in a different mechanism (Docker image) only to allow it to be copied into another image ... rather than using an existing installer (such a snap). In such cases a minimal docker file might be better for the distribution:

FROM scratch
COPY hello /
CMD ["/hello"]

We currently install task into containers this way:

...
# Go Builder
# ==========
FROM golang:bullseye as go
RUN GOBIN=/usr/local/bin go install github.com/rogpeppe/go-internal/cmd/testscript@latest
RUN GOBIN=/usr/local/bin go install github.com/go-task/task/v3/cmd/task@latest
...
COPY --from=go /usr/local/bin/task /usr/local/bin/task

but there are many other ways ... observe that I'm not using bookworm either. Copying from an existing container image would certainly be faster than building from source.

[mircea-pavel-anton]

Hi, @trulede !

You're right that, if the point of the dockerfile was just as an "installation" method, it would have been better to use scratch, but that's not really the point here.

Sure, the main usecase I personally have is just that, but there are other usecases in which this could make sense. For example:

• Runnning on an (corporate) environment where package installations or downloads from github are not allowed, but there is an internal registry mirror which mirrors dockerhub. Then, one could alias task to something like docker run -it --rm -v $PWD:/workspace <INTERNAL-REGISTRY>/docker.io/taskfile/task <task_name>
• Running a cronjob in k8s that executes some script in the form of a task
• Maybe this could be used as the base image for a Tekton task / CI pipeline step
• etc.

This is why I chose bookworm as a base. Given that it also runs bash, I was hoping to get bash completion working too for that initial example

[trulede]

We (I) find task to be useless without other tools which do the work. That makes putting task into a container for general purpose use a little bit futile - you might think otherwise, that's OK.

What we typically do is build an image for a purpose, and "mix" task into it. If task came from an existing container, sure, but perhaps also consider exactly which use case is really going to be viable (which distro, version , arch).

Also, most of the time we use task to run other containers (Docker in Docker) ... so rather curiously we get by with a fairly generic container image, which contradicts my previous statement a little - but only a little, because the image is still specialised for running testscript. That is what makes me sceptical of the benefit of running a generic task container - it's just a little bit different than those other tools (which act on systems, like k8, via ports etc).
.

Really, it does not bother me one way or the other. Certainly can be useful, as you mention.

[mircea-pavel-anton]

You make valid points, and I generally agree. Having it just by itself is a bit restrictive and it will most likely be "mixed" into larger dockerfiles. I just found it a lot easier to reference a centralized location cause I do this "mixing" process quite a lot.

I inject task into a lot of my devcontainers (almost all of them at this point) and having it this way would make that process a bit easier. I am totally fine with maintaining my own image just for that (I already do), if the community does not see value in this. I just thought I'd share in case others are in a similar situation