Consider Docker labels in lieu of "custom tags" about sbt-docker-compose

[kurtkopchik]

Hi @ches, thanks for the feedback and evaluating the plugin!

I agree, that adding the custom tags to a label instead of as part of the image value would make the compose file more portable for direct use by docker-compose. I certainly would be open to a PR that adds the ability to be able to define custom tags within a label.

Note that the custom tags mostly play a part in relating your docker-compose definition to a multi-project sbt build. If you are just using a more basic sbt project you should not need to use custom tags at all and the docker-compose file should be directly usable with docker-compose.

[ches]

Thank you for your prompt reply Kurt.

I think the plugin is 90+% of the way to serving my use case, I have a few questions about how things are intended to work that I'll ask through another issue to keep discussion here on the original topic (or if there's a Gitter or something that you'd prefer as a channel for questions, let me know).

There are some situations where the functionality currently provided by custom tags might be useful outside of multi-project builds, for instance I might already have the tagged image versions that I need pulled to my laptop and when I'm getting on a plane I want sbt-docker-compose to stop trying to hit the network to pull those images only to find the tag versions are still up-to-date locally. From what I can tell <skipPull> is a way to achieve that, even if it wasn't the intended use of it (?). There may be other ways to solve this, I'd probably prefer that such network pulls are avoided by default if a specific image tag is already available locally—as docker-compose seems to work—with an "always pull" option being the opt-in special case instead of "skip pull".

But regardless, multi-project use cases or not doesn't change whether labels might be a workable way to steer plugin behavior more portably. I think it's worth taking a stab at it.