On Tue, Aug 27, 2019 at 3:35 PM Hannah Jiang <[email protected]> wrote: > > Hi team > > I am working on improving docker container support for Beam. We would like to > publish prebuilt containers for each release version and daily snapshot. > Current work focuses on release images only and it would be part of the > release process.
This would be great! > The release images will be pushed to GCR which is publicly > accessible(pullable). We will use the following locations. > Repository: gcr.io/beam > Project: apache-beam-testing Given that these are release artifacts, we should use a project with more restricted access than "anyone who opens a PR on github." > More details, including naming and tagging scheme, can be found at wiki which > is written by several contributors. Would it make sense to put this in a format more amenable to commenting? > I would like to discuss these two questions. > 1. How many tests do we need to run before pushing images to gcr? > Publishing artifacts is the last step of the release process, so at this > moment, we already verified all codebase. In addition, many Jenkins tests use > containers, so it is already verified several times. Do we need to run it > again? > > 2. How many tests do we need to run to validate pushed images? > When we push the images, we assume the images would work and pass all the > tests. After pushing, we should confirm the images are pullable and useable. > I suggest we run several tests on dataflow with each pushed image. What do > you think? I think the release manager publishing these images as part of the release process (just like publishing to the maven repo and svn) and validation happens as part of validating the artifacts during the vote.
