Should we separate out publishing of amazeeio dockerhub images from Lagoon releases?

[tobybellwood]

Starting a discussion here about a thought we've been having internally.

Currently the amazeeio dockerhub images are published alongside Lagoon releases.

This has a couple of side-effects:

• The work required to release a new image update (eg a PHP minor version) is commensurate with releasing a full Lagoon update
• Each release of Lagoon also releases an updated set of images (the ones built and tested alongside it)
• Building and testing Lagoon images is hard without also building Lagoon, which may discourage contribution

This effectively reduces our ability to be as reactive on the image updates as we could be, and also makes patching/hotfixing Lagoon harder - although we can release Lagoon without images, the testing has all been performed on images that effectively aren't released.

Going forwards, there are a few proposals that I'd appreciate some discussion and contribution around.

1. Should we split out images from Lagoon - should it either be inside the repo with different Make commands, or via a separate repo?
2. Decide on a release cycle for images separate to Lagoon - is monthly enough, can we patch mid-month - does CalVer make sense?
3. Should we build a user-friendly test suite (e.g. CircleCI) around images to encourage contribution, and promote local development and testing?
4. Which images do you think could be split out - obviously php, nginx, node, mariadb, but what others?
5. Is there any interest in increasing public contribution to the "internal" images - e.g. EFLK, Harbor, oc/k8s - or is that primarily our concern given how tightly they're coupled to Lagoon?
6. Is there any interest in public contributed images for Lagoon - i.e. ones that work on Lagoon, but might not necessarily be fully developed/supported by amazee.io - this could include EOL ones, niche extension use cases etc?
7. Anything here we've not thought about?

There are a few definite points if we go with this strategy:

• Lagoon stable (released) will have to be tested against latest (develop) images
• Lagoon latest (develop) will have to be tested against stable (released) images.
• Where we creates example projects (e.g. https://github.com/amazeeio/drupal-example) - these should also be configured to test against stable and latest images.

I'm happy to open this discussion up to thoughts, recommendations, requests and comments - let me know what you think!

[smlx]

A few thoughts:

1. I'd love to see complete decoupling of image versioning from Lagoon releases. Monorepo or separate repositories or maybe just split into a couple of different repositories like "services", "base images" etc.

2. Does Lagoon match the CalVer "When to Use" section?

3. ❤️ yes please. Each microservice / base image with its own test suite would make it much easier to test changes locally before going full Jenkins.

4. Everything under services/ too IMO.

5. Not sure.. how would you increase this?

6. A "contrib" or "community" repo with best-effort support would be useful for those edge cases.

What will remain in the main Lagoon repository? Docs, helm charts, and an integration test suite?

[fubarhouse]

+1 to item 4. 🤘

[shreddedbacon]

+1 to item 1. This cropped up with the recent release of 1.7.1 and the only change being to a solr image.

[smlx]

We should also split out the helm charts and have them in their own git repo with CI generating packages and pushing to a chart repo.

[tobybellwood]

for sure - we talked about this briefly before - We could use GitHub, Harbor or host our own ChartMuseum - there are obviously more options too!