mailhog / MailHog

Web and API based SMTP testing
MIT License
14.12k stars 1.07k forks source link

Official Docker mailhog image #283

Open Lewiscowles1986 opened 4 years ago

Lewiscowles1986 commented 4 years ago

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).

geerlingguy commented 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.

Lewiscowles1986 commented 4 years ago

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.

Lewiscowles1986 commented 4 years ago

It is working on my raspberry pi zero and raspberry pi 4 (64-bit aarch64 under docker)

chadxz commented 4 years ago

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?

thaJeztah commented 4 years ago

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

ap-wtioit commented 4 years ago

@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

thaJeztah commented 4 years ago

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.

Lewiscowles1986 commented 4 years ago

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)

Lewiscowles1986 commented 4 years ago

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?

Lewiscowles1986 commented 4 years ago

The image is now building with mainline as of yesterday. No more pinning to an old (I'm told out-of-date golang)