Open ilya-hontarau opened 4 months ago
Any public registry will make us happy I guess. I prefer ghcr over docker hub personally.
Hi @ilya-hontarau, sorry for the late reply. We're just trying to sort out the current release and then we can look into this.
Out of interest, may I ask what is your use case?
@andrews05 we are using precommit with an oxipng hook. a few of our team members are too lazy to download precommit, and just manually run oxipng instead. particularly, manually run oxipng via Docker.
some dude posted an oxipng Docker image a year ago but that's outdated now. https://hub.docker.com/r/videah/oxipng
Just as a test, I've published an image under my own user: https://github.com/andrews05/oxipng/pkgs/container/oxipng If this is helpful we can look at setting up a workflow (don't rely on this one to stick around forever).
I guess I'm a little puzzled by the need to use docker to run a single binary with no dependencies. Wouldn't it be easier for your team members to just install oxipng directly?
I guess I'm a little puzzled by the need to use docker to run a single binary with no dependencies. Wouldn't it be easier for your team members to just install oxipng directly?
Yeah, that puzzles me quite a bit too. I've also received requests to release another single-binary, no-setup Rust application as a Docker image, and, to be honest, I'm still grappling with the value proposition of Docker in such scenarios.
OxiPNG isn't really designed for deployment or orchestration like archetypical web application services. Besides, most sysadmins and DevOps professionals I've seen can already leverage artifacts like Debian packages for automating provisioning.
The most compelling use case for Docker images in these cases I've found so far is to (ab)use them as some sort of "action steps" for GitLab CI workflows. However, if you're concerned about keeping the image lightweight and go distroless, which entails removing the shell and other basic tools from the image, the image can get quite cumbersome to use with GitLab.
Maybe I haven't delved deep enough into the Docker ecosystem to grasp the usefulness of this suggestion fully, but I'm left wondering: what problems does a OxiPNG Docker image actually solve?
@AlexTMjugador
In general people like to not download stuff unless they need to. That's how I optimize screenshots in our documentation repo:
docker run --rm -v $PWD:/workspace author/oxping /workspace/assets/screenshot_01.png
CLI tools having Docker images aren't unheard of at all, this request usually doesn't come as a surprise to maintainers.
Thanks for the clarification! I also try to avoid downloading stuff I don't need, but Docker images have to be pulled (i.e., downloaded) before use anyway. A Docker image is, for this purpose, just another way of downloading the binary, but with extra overhead for the image metadata and such. It doesn't really get more portable, or require less system modifications to set up.
However, I'm thinking that a Docker image could be useful if you're looking into scaling with Kubernetes, so you can spawn OxiPNG containers to handle incoming requests as required. That integration is, frankly, something that cannot be achieved well without Docker images. What do you think about this?
It will be good to build and push on each release an image to dockerhub.