It has been desired to do sanity test before ONAP code is merged. It will help developer to get quick feedback and committer to make informed decision whether to merge the patch set. The result is better ONAP code quality and less integration debugging. This approach has been proven very useful in OOM gating by Orange team. We want to extend the approach to other ONAP components.   A general proposed approach (subject to further discussion) based on Integration meeting on 07/10/19 would be:

1. Deploy a released or verified version of ONAP in one of Integration tenants
2. A Jenkins job, listening to Gerrit commit notification, receives an ONAP code commit event
3. A Jenkins job triggers to pull the newly committed patchset 
4. Invoke a Maven process to build container images for the affected ONAP component either in LF,  locally or in a remote server. The preferred method is to invoke LF job to build image so that image is the same as the final released image. As the PoC, we can pull repo and build images locally as developers do in their env. 
5. Label newly build container images with gerrit id information and push container images to dockerhub or other image repo
6. Redeploy the affected ONAP component with integration-override.yaml in the working ONAP from Step 1
7. Check all pods are up and run Robot healthcheck, healthdist, and vFWCL 
8. Post test result from the above step and make recommendation (-1, 0, +1) to Gerrit for the committed patchset
9. Restore ONAP back to the working version as in Step 1
10. Some job to periodically clean temporary container images in dockerhub or other image repo we choose

The process should apply to any ONAP component. We can start with experiments on some ONAP component which is easy to build container images locally.