Should Mailhog be converted to run as a global shared service?

[davidalger]

Currently each environment runs it's own Mailhog container to capture emails relayed via SMTP. This seems quite redundant and inefficient when spinning environments up and down.

The idea here is that Mailhog would run as a shared global service in like manner to Traefik, Portainer, etc. It would be peered with each project network (just like Traefik is) allowing php-fpm containers to continue sending email to mailhog on port 1025 (i.e. there should be zero re-configuration of application configuration for this to work).

Implementing this change would have mailhog service spun up when warden svc up (formerly warden up) is run and would obsolete the WARDEN_MAILHOG flag in per-project .env files as it would no longer have a purpose.

Users who do not want to run Mailhog for any of their projects (despite it being very lightweight) could be empowered to turn it off by implementing a similar flag in the global service .env file typically found at ~/.warden/.env PHP-FPM images are built with mhsendmail pre-configured to route outbound emails to mailhog:1025 and overriding this based on a global svc presence indicator would be difficult, so implementing a global flag to avoid running mailhog at all is unlikely at this time.

Any thoughts on this front are welcome. Should there be no opposition to the idea, it will likely be explored in context of 0.7.0 release (timeline tbd).

[davidalger]

This has been implemented in commit 12d8452 and has been working well. The change will be published in the upcoming 0.7.0 release.