Docker tag `latest` was last updated 2 years ago

[dhruvkb]

Is Docker no longer a recommended way to use imaginary? As per the Docker Hub tags, the tag latest was pushed 2 years ago.

While I can see that the library is being actively maintained, there aren't any M1-compatible arm based images on Docker Hub either. If not via the official Docker image, what's the recommended approach to use this library?

[dhruvkb]

At Openverse, we've created a multi-arch (linux/arm64 + linux/amd64) Docker image of imaginary, hosted on GHCR. Leaving this here in case it helps anyone looking for updated Docker images. Here is the workflow we used to generate this image. Feel free to use it if you'd like a CI pipeline to build Docker images regularly.

We had to make 2 changes to the Dockerfile for the builds to succeed.

• From Build image from Dockerfile error after commit 00f696fe3a3211fb7d01450b9f81308e17c56ca3 #387:

  sed -i 's/bimg v1.1.4/bimg v1.1.7/' go.mod
  go mod tidy

• From race: 'unsupported VMA range' on linux/arm64 golang/go#29948

  sed -i 's/RUN go test/# RUN go test/' Dockerfile
  sed -i 's/RUN golangci/# RUN golangci/' Dockerfile

[ItalyPaleAle]

I've been building updated Docker images myself and you can find them on GHCR: ghcr.io/italypaleale/imaginary:master It's multi-arch for linux/amd64 and linux/arm64, and it's built automatically with an Action.

This is from my fork, which fixes the issues you've identified above and a few more changes (including #386 ). It also updates the base image to Bullseye. Full diff: master...ItalyPaleAle:master

You're welcome to use those images too, although note that I offer no guarantee on their support :)

[dhruvkb]

@ItalyPaleAle while we made only the bare minimum changes needed to compile the image, you've made some very notable improvements to both the code and the Dockerfile.

I'll definitely try to see if your images can fit into our use and if the team agrees we'll drop our version and switch to yours. Thanks for working on this, it'll help a lot of folks wanting to use the updated code as a Docker container.

[ItalyPaleAle]

@dhruvkb

The code changes are actually fairly minimal. The only "real" code change is what's in #386 (the other changes to the Go file are due to gofmt running when I saved it).

The biggest changes are:

• I fixed the build errors, similar to what you identified
• I updated the dependencies because I needed a more recent version of libvips for my own project. That required updating the Go deps too like h2non/bimg
• I updated the base Dockerfile to one based on Debian Bullseye (from Buster). Bullseye comes with an updated libjemalloc so it doesn't need to be built from source anymore.
• I separated the "prod" Dockerfile from the test one, which is used to run tests

Aside from that, the other changes were more about the engineering processes themselves:

• I created a GH Action that builds the container and publishes it to GH Packages, and this runs periodically so we have an updated container too
• I created a dev container (now merged upstream in Added dev container #385) because if you use VS Code, they make your life much, much better, especially given how imaginary has dependencies on native code :)

Thus said, if you/your team think my changes are valuable to you too, I'd very gladly grant you access to my repo too, or even transfer it to you :)

[sarayourfriend]

@ItalyPaleAle Thank you for the offer to transfer the repository over to us! I'll add this to our agenda to discuss during our community meeting tomorrow, which you are welcome to join us for in the WordPress Make Slack. You can follow the instructions on this page to make an account and access it: https://make.wordpress.org/chat/. Then you can find us in the #openverse channel. The community meeting happens at 15 UTC on Tuesdays on a weekly basis. No worries if you can't make it though, I'll leave an update on our discussion about it here.

[ItalyPaleAle]

Thanks @sarayourfriend ! Sadly, I am not able to join tomorrow because of a conflict, but you can contact me directly at github [at] [my GitHub username] [dot] com should you need anything.

[sarayourfriend]

@ItalyPaleAle We discussed it and I think we're going to stick with publishing our own image for the moment, adding a big disclaimer that we're not seeking to actively maintain a fork of upstream. We will probably borrow some of the improvements you made though and be sure to Co-authored-by: you on the commits so you show up in our contribution log (if you're okay with that).

[ItalyPaleAle]

Sounds good, thanks for letting me know. I may just stop maintaining mine then and adopt yours.

[bluepuma77]

I would assume a lot of people just search docker hub for Docker images and find https://hub.docker.com/r/h2non/imaginary

Why not 1) keep it up to date or 2) at least leave a depreciation notice with a link to the new repository?

[ItalyPaleAle]

Note that the repository linked here is an unofficial fork!

[bluepuma77]

@ItalyPaleAle Sorry, I don't understand, which is an unofficial fork?

1. https://github.com/h2non/imaginary
2. https://hub.docker.com/r/h2non/imaginary/

Github page clearly states to use docker pull h2non/imaginary (which is on Docker Hub). If the Docker repository is unofficial, why is is mentioned in the official documentation?

[ItalyPaleAle]

I'm sorry, I thought you were talking about the forks that we've been mentioning in this thread. Please disregard.