...

High Level Artifact Build Flow

Ideally, the docker image build process should be fully separated from the Java/Python artifact build process.  This means:

• One set of Jenkins jobs will build and deploy Java/Python artifacts to Nexus
• One set of Jenkins jobs will build the docker images using Java/Python artifacts already deployed to Nexus before
• Jenkins job dependencies should be set up so that the former can trigger the latter

Once we include considerations of the SNAPSHOT/ STAGING/RELEASE docker tags, we end up with the following general development/release flow:

1. Produce SNAPSHOT Java artifact.  Test this in a SNAPSHOT docker image.
2. Produce staging (release candidate) Java artifact.  Test this in a SNAPSHOT docker image.
3. Produce release Java artifact by picking one of the candidates from staging. 
4. Produce STAGING docker image using the release Java artifact.  Use this in build artifacts, compile them into docker images and test them with CSIT locally.
5. Push the changes to gerrit to produce build artifacts and docker images from submitted patch and have them tested by CSIT in Jenkins review verification. 
6. Merge verified changes to produce build artifacts and docker images from master and have them tested by CSIT in Jenkins merge verification. 
7. Release the artifacts that pass merge verification.
8. Produce STAGING docker images from the released artifacts.  These are applicable for higher level E2E test flows.
9. Produce RELEASE docker image images by picking one of the candidate STAGING docker images that have passed E2E tests. 

Migrating from OPEN-O Docker Builds

...