Generally you would push to a tag (could be latest, could be "stable",
could be "dev") and then when you accepted that image you could tag it in
with "oc tag mystream:stable mystream:v1.3" to record which one was that
version. Alternatively, every time you start a new release chain you could
start pushing to the desired tag ("v1.3") and then when you move to the
newer version start pushing a new tag. You can then manually tag in "v1.3"
into "latest" when you are ready to deploy it. If you are dealing with
large sets of images, you may want to move to more of a config driven
approach where you your config checked into source control and then have
your test / development flow actually test in the actual image references
into the Git repo. There's no one right answer, but generally the more
complex you get the more effective a "treat openshift API objects as
configuration and us a configuration management tool" will be.
On Mon, Sep 19, 2016 at 8:45 AM, Den Cowboy <dencow...@hotmail.com> wrote:
> At the moment we are pushing our images with tag 'latest' to the OpenShift
> Docker Registry. For example inside the test project.
> This will create and image-stream to that image + we start our
> container/service/pod with oc new-app my-image:latest.
> When we create a new image we build it again + tag with latest + push it.
> The image-stream will be updated and a new deploy will be triggered.
> This is working very well but it's difficult to use for our versions
> because we always need to tag with latest.
> We are able to push with the tag :latest + with tag :1.0.0 but this isn't
> the best solution for us. (for example when you want to go back to an
> earlier version you also have to tag the 'older' image with tag latest to
> trigger a new deploy.
> Is there a recommended way to use verions + automatic deploys in the
> OpenShift Registry?
> Something like: every push of an image triggers a new deploy (tag does not
> matter) or some other good way?
> users mailing list
users mailing list