Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Ideally, the docker image build process should be fully separated from the Maven (Java/Python/etc.) artifact build process.  This , but this doesn't seem to have been applied in ONAP (?)  This means:

  • One set of Jenkins jobs will build and deploy Java/Python Maven artifacts to Nexus
  • One set of Jenkins jobs will build the docker images using Java/Python Maven 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. Maven artifacts, build them into docker images and test them with CSIT locally.
  5. Push the changes to produce SNAPSHOT Maven artifacts and docker images from submitted patch and have them tested by CSIT in Jenkins review verification. 
  6. Merge verified changes to produce SNAPSHOT Maven artifacts and docker images from master and have them tested by CSIT again. 
  7. Successfully verified docker images are tagged with STAGING.  These are applicable for higher level Produce STAGING docker image using the release Java artifact.  Use this in E2E test flows.
  8. Produce RELEASE docker image by picking one of the candidate STAGING docker images that have passed E2E tests. 

Migrating from OPEN-O Docker Builds

...