Sounds good. I set up the bintray stuff a while ago but got stuck on perms to have Jenkins upload the snapshot, and the release was not really relevant.
Kenn On Wed, Jan 16, 2019 at 5:37 PM Ahmet Altay <al...@google.com> wrote: > > > On Wed, Jan 16, 2019 at 5:28 PM Ankur Goenka <goe...@google.com> wrote: > >> - Could we start from snapshots first and then do it for releases? >> +1, releasing snapsots first makes sense to me. >> - For snapshots, do we need to clean old containers after a while? >> Otherwise I guess we will accumulate lots of containers. >> For snap shots we can maintain a single snapshot image from git HEAD >> daily. Docker has the internal image container id which changes everytime >> an image is changed and pulls new images as needed. >> > > There is a potential use this may not work with. If a user picks up a > snaphsot build and want to use it until the next release arrives. I guess > in that case the user can copy the snapshotted container image and rely on > that. > > >> - Do we also need additional code changes for snapshots and releases to >> default to these specific containers? There could be a version based >> mechanism to resolve the correct container to use. >> The current image defaults have username in it. We should be ok by just >> updating the default image url to published image url. >> >> We should also check for pricing and details about Apache-Bintray >> agreement before pushing images and changing defaults. >> > > There is information on bintray's pricing page about open source projects > [1]. I do not know if there is a special apache-bintray agreement or not. > If there is no special agreement there is a 10GB storage limit for using > bintray. > > [1] https://bintray.com/account/pricing?tab=account&type=pricing > > >> >> On Wed, Jan 16, 2019 at 5:11 PM Ahmet Altay <al...@google.com> wrote: >> >>> This sounds like a good idea. Some questions: >>> >>> - Could we start from snapshots first and then do it for releases? >>> - For snapshots, do we need to clean old containers after a while? >>> Otherwise I guess we will accumulate lots of containers. >>> - Do we also need additional code changes for snapshots and releases to >>> default to these specific containers? There could be a version based >>> mechanism to resolve the correct container to use. >>> >>> On Wed, Jan 16, 2019 at 4:42 PM Ankur Goenka <goe...@google.com> wrote: >>> >>>> Hi All, >>>> >>>> As portability/FnApi is taking shape and are compatible with ULR and >>>> Flink. I wanted to discuss the release plan release of SDKHarness Docker >>>> images. Of-course users can create their own images but it will be useful >>>> to have a default image available out of box. >>>> Pre build image are a must for making FnApi available for users and not >>>> just the developers. >>>> The other purpose of these images is to be server as base image layer >>>> for building custom images. >>>> >>>> Apache already have bintray repositories for beam. >>>> https://bintray.com/apache/beam-snapshots-docker >>>> https://bintray.com/apache/beam-docker >>>> >>>> Shall we start pushing Python/Java/Go SDK Harness containers to >>>> https://bintray.com/apache/beam-docker for beam release and maintain >>>> daily snapshot at https://bintray.com/apache/beam-snapshots-docker ? >>>> >>>> Thanks, >>>> Ankur >>>> >>>
