...
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:
- Produce SNAPSHOT Java artifact. Test this in a SNAPSHOT docker image.
- Produce staging (release candidate) Java artifact. Test this in a SNAPSHOT docker image.
- Produce release Java artifact by picking one of the candidates from staging.
- Maven artifacts, build them into docker images and test them with CSIT locally.
- Push the changes to produce SNAPSHOT Maven artifacts and docker images from submitted patch and have them tested by CSIT in Jenkins review verification.
- Merge verified changes to produce SNAPSHOT Maven artifacts and docker images from master and have them tested by CSIT again.
- 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.
- Produce RELEASE docker image by picking one of the candidate STAGING docker images that have passed E2E tests.
Migrating from OPEN-O Docker Builds
...