THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
This section describes the naming scheme and location for publication of the containers.
Proposed repository:
We propose to use gcr.io/beam, created under apache-beam-testing project, artifacts accessible publicly. SDK Harness containers go to sdk folder.
...
| Naming | Tagging | Example | |
|---|---|---|---|
| Snapshot image | language + language_version | yyyymmdd_{status} in UTC | gcr.io/apache-beam-testing/beam/sdk/snapshot/yyyy2019/mm08/dd20/java:20190820_verified |
| Release images | language + language_version (Java and Go go without language version until we support itmulti versions.) | Beam release version | gcr.io/apache-beam-testing/beam/sdk/release/python2.7:2.10.1 gcr.io/apache-beam-testing/beam/sdk/release/java:2.10.1 |
Publication Schedule
Snapshots
...
- how should we build and publish the images for release versions of Beam?
- manually, as part of Beam release;
- or by automatically triggering a job at some step of the release?
- should it be a blocker for the release?
- should we make it part of the release and not mark release as complete until the images are published?
- For first three release(v2.16 ~ v2.18), we can make it optional, and if all these release go well, we can make it mandatory part of the release(from v2.19).
- should it be done by the same release owner?
- Yes, this document provides step by step guide about building, testing and pushing. In future, we can automate this process.
- should the validation be part of the release validation?
- Yes.
- should we make it part of the release and not mark release as complete until the images are published?
Commands
This section describes the commands that are used to build, publish, run tests and examples for the images.
...