> For the unreleased version of SDKs, the default tag will be version number + '.dev'. (ex: 2.18.0.dev) >> Shall we ALSO tag the image with git commit version for local build to keep track of obsolete images.
I should clarify it more clearly. This is about release images. The dev images are only available locally when a developer builds it from a dev version. Release images are deployed to docker hub each time when we release a new version of Beam. Deploying snapshot images are on our to-do list, it will be tackled separately later. On Thu, Jan 9, 2020 at 5:09 PM Ankur Goenka <[email protected]> wrote: > >> For the released version of SDKs, the default tag will be version > number. (ex: 2.17.0) > +1 > > >> For the unreleased version of SDKs, the default tag will be version > number + '.dev'. (ex: 2.18.0.dev) > Shall we ALSO tag the image with git commit version for local build to > keep track of obsolete images. > > On Thu, Jan 9, 2020 at 4:54 PM Kyle Weaver <[email protected]> wrote: > >> > This has a minor downside for the users who are using unreleased >> versions. They need to build a local image first before using docker to run. >> >> Isn't that the current behavior? >> >> On Thu, Jan 9, 2020 at 4:48 PM Hannah Jiang <[email protected]> >> wrote: >> >>> Hi Community >>> >>> Now we are using different default tags for Python(version or >>> version.dev), Java(version-SNAPSHOT) and Go(latest). I would like to >>> clean it up and make it consistent for all languages and here is my >>> proposal. >>> >>> For the released version of SDKs, the default tag will be version >>> number. (ex: 2.17.0) >>> For the unreleased version of SDKs, the default tag will be version >>> number + '.dev'. (ex: 2.18.0.dev) >>> >>> The default tag is used 1). when we build docker images without >>> specifying a tag. 2) when we run a job with runners running on dockers with >>> default docker images. >>> >>> Additionally, Beam will always lookup images locally before pulling one >>> from remote, so the images built locally will not be overwritten by remote >>> ones. >>> >>> This has a minor downside for the users who are using unreleased >>> versions. They need to build a local image first before using docker to >>> run. I will add a clear error message to show the problem and add a link to >>> a documentation of how to create images. >>> >>> I would like to collect feedback from whoever uses dockers. Does this >>> sound good? Is there anything I am missing? >>> >>> Thanks, >>> Hannah >>> >>> >>> >>> >>> >>> >>> >>>
