Closed mikegirkin closed 7 years ago
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:
docker push
command in the plugin. In this scenario, any retagging should be done externally (e.g. by a deployment pipeline). version in ecr
to tag in ecr
for the same effect (1), but more docker-friendly terminology. version in ecr
, provide tags in ecr
instead and support the multi-tag push. 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.
@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.
@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:
DockerPlugin
from sbt-native-packager (i.e. the dockerUpdateLatest
setting).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:
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).ecr:repositoryTags
. Thoughts?
@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
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"