Consider Docker labels in lieu of "custom tags"

[ches]

I'm evaluating sbt-docker-compose and the primary thing that first attracted me to it—as opposed to possible alternatives like docker-it-scala which leaves me to duplicate container definitions in yet another config format—is the hope of reusing perfectly good existing Compose configs that people can use in their local development with standard docker-compose, independent of sbt-docker-compose.

Adding custom preprocessed extensions to the file format like <localBuild> and <skipPull> breaks compatibility of the files with the standard tools. IMO this is a fundamental design misfeature.

I'd like to propose that custom labels could potentially fill this need instead, and likely make further extensibility easier to boot (you could abstract a contract for an sbt-docker-compose label processor instead of requiring processCustomTags specifically to be overridden).

As I said I'm still evaluating, but if the plugin otherwise meets my needs, I'll try to whip up an implementation as a PR.

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