Open Lewiscowles1986 opened 4 years ago
I also noticed that the current mailhog/mailhog:latest
image was last updated 2 years ago (https://hub.docker.com/r/mailhog/mailhog/). It would be great if the build could be automated so it is pushed out when this repository/project is updated.
It can be. One caveat right now, is that as well as building, ideally tests need to be created for each platform, so artifacts need to be put through some holding pattern or sample testing on hardware. That side of things gets less repeatable.
It is working on my raspberry pi zero and raspberry pi 4 (64-bit aarch64 under docker)
does anyone know if there are any blockers for this to be done? Or is it simply that a PR hasn't been submitted to setup a CI/CD pipeline for this project?
Some information on becoming an official image can be found here; https://docs.docker.com/docker-hub/official_images/#creating-an-official-image
Happy to connect maintainers of this project with the official images maintainers if needed
@thaJeztah i think this issue is for updating the current mailhog image https://hub.docker.com/r/mailhog/mailhog/ with a more up to date code and not for creating a "Docker official" image https://hub.docker.com/_/mailhog
Looking at the code itself, there's been no code changes (to the Go source code itself) since v1.0.0 was tagged (https://github.com/mailhog/MailHog/compare/v1.0.0...master), so from that perspective there's no "more up to date code". Note that the binary itself is static, so rebuilding likely won't bring an advantage (but wouldn't hurt, e.g. to build with a more recent version of the Go runtime). w.r.t multi-arch images; I know the official images have infrastructure in place for this, so that would be an option.
As the original poster. I wanted to know if a PR would be acceptable. I will make one. Unfortunately the base image seems to have broken arm64 builds within the past 2 weeks (no source changes, just upstreams being trash)
Fixed by pinning version to 1.12-alpine docker image for now. Would @geerlingguy be able to review a PR if I make one, and @thaJeztah be able to help connect to Docker people for an official _/mailhog (docker library) version?
The image is now building with mainline as of yesterday. No more pinning to an old (I'm told out-of-date golang)
Hello 👋
thank you so much for writing this amazing software. So amazing I've never had to touch the code to change, only build.
One of my long-term frustrations has been multi-arch support.
I've just got this merged into https://hub.docker.com/repository/docker/cd2team/mailhog which is on GitHub at https://github.com/CODESIGN2/mailhog-docker
The build is < 10MB for all platforms, so very thin, supports Ci builds for the following architectures
I would be interested in handing this work back upstream like a good open source contributor, so people can benefit from the author as the primary upstream distributor.
Please let me know if you're open to a PR for this and if you could take a look, anything you'd need changed.
Alternatively if it's cleaner I'm happy to transfer the repository to you (I'd have to delete my GitHub secrets) so that people wanting to know how the docker is built wouldn't need to look at the golang code (my personal preference is to keep repo's separate).