NO-TICKET: dockerPublishTags SettingKey

[ferhtaydn]

dockerPublishTags is added for extra publish tags support.
See sbt/sbt-native-packager#979

If you want to close publishing latest, just add dockerUpdateLatest := false to you project module in your build.sbt.

[dhpiggott]

What's the use-case for this?

[ferhtaydn]

You can use this setting key if you need to publish your docker image with arbitrary tag(s) apart from latest and version of your project. It may be useful for testing specific features/versions/branches at the same time without overriding the existing image. It is just a small helpful setting key to ease an existing feature of docker native packager (and docker itself, of course) like dockerComposeUpExtras and dockerComposeUpLaunchStyle in CakeDockerComposeKeys.

[dhpiggott]

Given we already use the git-sha-derived version as the tag, I don't see a problem to solve. I think you're describing a scenario like this:

1. On a given project master currently points to commit 37461d, while myfeature points to commit d902e4.
2. For some reason we want to publish an image built from myfeature.

If my understanding is correct, the existing sbt-cake arrangement of things already supports this; we can simply trigger a publish from myfeature and the image will be tagged as d902e4, i.e. it will not collide with any existing tags.

[ferhtaydn]

👍 yes, we always have git-sha-derived version info by build-plugin. By following line in CakeDockerPlugin, sbt-cake is doing what exactly you are saying.

version in Docker := sys.props.get("tag").getOrElse(version.value)

with tag property one can even use any named tagged docker images.

The only thing remained in this PR to add publishing multi tagged images at ones instead of changing tag and publish again. It may be helpful if you are in an environment and want to publish multiple of versions at ones in your CI etc.

It is not a problem solver, just a minor nice to have feature. :)

[dhpiggott]

It may be helpful if you are in an environment and want to publish multiple of versions at ones in your CI etc.

Do you mean one image (same actual content, bit for bit), but different names for it? Presuming so, can you give a specific example of a use case?