Consider letting ddev's docker repositories cohabitate with ddev in the same repo

[rfay]

From @rfay on June 14, 2017 15:55

What happened (or feature request):

Our ddev containers (web, db, dba) are now very specialized to ddev and are unlikely to be used with anything else, at least we have no plans to do so.

It's worth considering whether we could move the docker recipes and builds into ddev's repo. That way the tags would always track, it could be pretty easy, although it would require a little bit of magic, since ddev's git version changes all the time, and we'd want to rely on the correct pushed container version.

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else do we need to know:

Related source links or issues:

Copied from original issue: drud/mysql-docker-local#19

[rickmanelius]

This is a valid issue. Tagging with hibernate and waiting until 1.0 when other things settle out a little.

[rickmanelius]

To be more explicit. I'm not necessarily saying we move forward with this approach. It might require some overall thought on the overall strategy of how/where we manage container versions. Adding "need decision" label to indicate that.

[tannerjfco]

I think there's value in maintaining them as separate projects. While it's unlikely our containers built for ddev will see much use outside of ddev, it is quite possible that a user might want to use on as a starting point if they require a customized version for their projects. It would be much easier for them to do so if it is treated as its own project. They could also be useful for general reference, should someone else building a container encounter it as example.

I think it's also possible that we expand our container offering in the future, potentially providing alternatives for web and db containers. We could end up with quite a few containers that could be considered part of ddev, which could make tracking in a single repo unwieldy.

[rickmanelius]

I think I'm going to move this back to hibernate. It's a good idea and I agree with it in theory. However, until we know how end-users start engaging with all of this, it's unclear if this will add value. There are other areas that we can add value now and therefore we should deprioritize this for now.

[rickmanelius]

There is a broader initiative being discussed within the local dev tool community in Drupal, specifically on sharing and/or collaborating on containers. If that gains any sort of traction, I think that's a vote in the direction of keeping them separate as they are now. Additionally, a lot of time has passed on this item with no traction and it's not a pressing priority, so I'm going to close for now and we can re-open if this is becoming a blocker/pain point.

[rfay]

Sorry, this issue is about how we manage our own code. It's about consolidating into a single repository, as has been done in hosting.