Closed sixeyed closed 2 weeks ago
@glyif be aware that this is a proposal, and was not yet decided on, so design has to be reviewed still.
e.g., Things I can think of is;
--image foo:bar
and --tag baz
were provided--publish
without affecting other options@thaJeztah, thanks for the heads up. I'll hold off on this then until a decision has been made :)
ping @dnephin @vdemeester @aaronlehmann any thoughts?
I don't feel strongly for or against adding a --tag
flag. All the normal concerns apply about having two flags that are similar but have different semantics. But I can see that a --tag
flag would be convenient in some cases.
maybe we can use a different flag other than --tag? thoughts?
I don't like the idea of having two flags that do basically the same thing.
@dnephin @thaJeztah @aaronlehmann what are good next steps? should this be implemented?
Just checking up on this, have some time this weekend to work on it if you peeps are ok with it 🍡
@dnephin - just following up here. The idea is that they don't do the same thing. --image
lets you update the service to any image, --tag
(or whatever) would force you to use the same image repo, but update to a different tag. I think it fits nicely with immutable repos.
It looks like there's no real consensus on this one. I'm closing this ticket for now, but we may change our mind in future 😅
This is a feature request. Currently you can only update services with
--image
. You can replace a service with another image altogether, but there's potential for error when you only want to update to a new tag from the same image repo.In a workflow where your release version is in the tag, you wouldn't normally update by anything other than the tag.
docker service update --tag v1.2.3
(or similar) would support that, removing the risk of updating one service with the image for a different service.