Ability to set arbitrary tags for the image

[mikegirkin]

With the release of 0.5.0 the image marked as "latest" only when the version is not provided in ecr.
Here is the PR that allows putting arbitrary tags to the image, i.e. "latest"

[sjednac]

Thanks for the contribution @mikegirkin. Before we merge this, I'd like to understand the use-case a bit better, as I feel 2 attributes are somehow redundant in this scope.

the image marked as "latest" only when the version is not provided in ecr.

If you skip the version in ecr setting entirely, or set it's value explicitly to latest, then you should still get the old behaviour. I assume your goal is to publish something like myimage:0.1.0 and myimage:latest using a single sbt task?

Regarding the plugin contract and the proposed change:

1. We could leave it as is and support only a single docker push command in the plugin. In this scenario, any retagging should be done externally (e.g. by a deployment pipeline).
2. We could rename version in ecr to tag in ecr for the same effect (1), but more docker-friendly terminology.
3. We could remove version in ecr , provide tags in ecr instead and support the multi-tag push.
4. We could merge it as is and support the multi-tag push along with the version tagging.

I think I need to think this through as all options seem to have good arguments for and against.

--
@ryancerf: Please feel free to comment on this as it's closely related to #6.

[mikegirkin]

@sbilinski My usecase is exactly the one you described. I want to have exact version marks, as well as "latest" tag, to refer to the latest release.
I actually need both of the tags. Let me explain what we do in Gilt. Version tag is using to mark the exact version of the app, so I could rollback production to the given version in case of screwed release. I refer to the version now in production from another services (particulary AWS Batch) as "latest", so I don't need to update the job descriptions whenever I release stuff. At the moment I just use the release bash script to do the release, but with that change I wouldn't need that script at all.
I also see some use around another tags, like "staging", "pre-release" or similar.
I'd like to keep version tags mandatory, as they are very well aligned with java-maven-sbt way of releasing stuff.

[sjednac]

@mikegirkin Thanks for the explanation - makes perfect sense. Frankly speaking, I did not need it myself, since we assumed a roll over policy at this stage of process and a single tag was sufficient so far.

That being said, I think multi-push would fit well within the scope of this plugin:

1. There's a similar concept in the DockerPlugin from sbt-native-packager (i.e. the dockerUpdateLatest setting).
2. It was made exactly to avoid redundant bash scripting around the deployment process :)

I'm leaning towards option 3, which would involve removing version in ecr completely and replacing it by something like:

lazy val repositoryTags   = settingKey[Seq[String]]("Tags managed in the Amazon ECR repository.")

That way, we could write everything in one place:

repositoryTags in ecr := List(version.value, "latest")

I'd keep List("latest") as the default value so that you don't have to provide this setting, if you don't need to.

My reasoning is as follows:

1. Neither ECR nor Docker uses the "version" term - it's all about tags.
2. repositoryTags reflects the fact, that these are "tags", which live in ECR (i.e. are unrelated to the local docker image, that is being pushed).
3. It keeps thing simple as all targets are instantly available via ecr:repositoryTags.

Thoughts?

[mikegirkin]

@sbilinski I am totally okay with that, as it was close to my initial idea, but when I did that PR I just didn't want to do that kind of a breaking change. I'll do that shortly

[sjednac]

Looks good - thanks! I just have one minor remark regarding the old setting (see comments).

[sjednac]

I think we can safely remove import sbt.Keys.version after removing this setting. Also, please update the README.md file as it still references version in the example.