Overview of the verification flows

The following diagram illustrates the proposed new review verification and merge verification flows

1. Developer pushes a commit to Gerrit
2. Gerrit triggers review verification job in JenkinsDocker build job builds snapshot docker image(s) and pushes them to ONAP Snapshot Nexus
   • The template templates for review verification job is are in ci-management/jjb/integration/integration-templates-csit.yaml and currently , named as "{project-name}-review-unifiedverification-review<artifact type>-{stream}-PoC"
     • The only currently supported artifact type in review verification templates is maven 
   • The trigger is "gerrit-trigger-patch-submitted" and it is activated by any file change in the project
3. Review verification job triggers docker build job
   • The value of BUILD_ID Jenkins variable is passed to the docker build job as UNIQUE_DOCKER_TAG (along with PROJECT, BRANCH and GERRIT_REFSPEC)
   • The triggered build is defined as  "{project-name}-{stream}-{artifact-type}-docker-snapshot-PoC" in the review verification job template
   • The build is blocking and fails the entire review verification job before moving it moves on to the next step on failure
   • The only currently existing docker build job template that follows the expected naming pattern is defined in ci-management/jjb/global-templates-golang.yaml as "{project-name}-{stream}-golang-docker-snapshot-PoC"
4. • the job starts with artifact build
     • Artifacts should be created from the patch under review
     • Currently the first step just compiles the artifacts locally (with unit tests), but additional operations - for example sonar analysis - should be considered here
5. Docker build is started
6. Docker build step builds docker image(s) to local temporary docker repository
   • The docker build scripts and the created artifacts are completely based on the submitted patch in Gerrit
   • The actual build script is specific to the project and has to be specified in the specific docker build job definition
   • The build should tag the relevant docker image(s) with <version>-SNAPSHOT-<unique docker tag> using the UNIQUE_DOCKER_TAG value given as parameter
   Review verification job triggers CSIT job
   • The value of BUILD_ID Jenkins variable is passed to the docker build job as UNIQUE_DOCKER_TAG (along with PROJECT, BRANCH and GERRIT_REFSPEC)
   • The triggered build is defined as "{project-name}-{stream}-project-csit-PoC" in the review verification job template
   • The build is blocking and fails the entire review verification job on failure
   • The CSIT job template is defined in ci-management/jjb/integration/integration-templates-csit.yaml as "{project-name}-{stream}-project-csit-PoC"the template differentiate local image from any that could be found from Nexus
     • For example, no repository prefix in the image name would be an obvious hint 
7. CSIT job is started
   
   • this step calls csit/run-project-csit.sh under the project's root directory via integration-run-project-test builder defined in ci-management/integration/integration-macros.yaml
   • run-project-csit.sh is project-specific, but can take advantage of common scripts in integration/csit if considered useful
   • run-project-csit.sh can and should run all the test plans of the project in one go and provide the results under csit/archives directory
8. CSIT job pulls the docker images created in step 4. (by using project-specific setup scripts) and tests them
   • The test cases to be executed are also from the patch under review
   • the setup script responsible of pulling the required images should ensure that the images are local
     • To be considered: should CSIT ever be able to pull the images under test from Nexus?
9. Review verification job gives +1 or -1 verify vote to the review based on the overall success of the verification
10. Once the commit is approved (+2'd) and submitted, Gerrit triggers merge verification job in JenkinsDocker build job builds snapshot
    • The template for merge verification job is in ci-management/jjb/integration/integration-templates-csit.yaml and currently named as "{project-name}-merge-unifiedverification-merge<artifact type>-{stream}-PoC"
    • The only currently supported artifact type in merge verification templates is maven 
    • The trigger is "gerrit-trigger-patch-merged" and it is activated by any file change in the project
11. Merge verification job triggers docker build job in exactly the same way as review verification is triggered in step 3.
12. • the job starts with artifact build
      • Artifacts should be created from master
      • Sonar analysis and other possible additional artifact-related steps should be considered here
13. Docker build is started
14. Docker build step builds docker image(s) and pushes them to ONAP Snapshot NexusThe procedure is the same as in step 4. except for the fact that the to local temporary docker repository
    • The docker build scripts and the created artifacts are completely based on master branch
    Merge verification job triggers CSIT job
    • The actual build script is the same as in review verification and used in the same way
15. CSIT is started in exactly the same way as review verification job triggers it in step 5.
16. CSIT job pulls the docker images created in step 10. (by using project-specific setup scripts) and tests themMerge verification job triggers docker image staging job
17. The value of BUILD_ID Jenkins variable is passed to the docker build job as UNIQUE_DOCKER_TAG (along with PROJECT, BRANCH and GERRIT_REFSPEC)
The triggered build is defined as 

Requirements and recommendations

The following requirements must be met and recommendations should be followed by any project that moves their CSIT tests to project repository:

• The project must define a review verification job based on one of "{project-name}-review-verification-<artifact type>-{stream}" templates (which is defined in ci-management/jjb/integration/integration-templates-csit.yaml)
  • the only currently supported artifact type is maven - new templates must be created to support different artifact types (such as golang)
    
    • The existing maven template assumes the following JJB variables for maven by default:
      •  mvn-goals: clean deploy
      • mvn-params: <empty> 
    • The purpose of these variables is to build both maven artifacts and then docker images containing the artifacts, but to not push either to Nexus
      • if your project uses different maven goals or parameters for achieving these, the above variables must be overridden appropriately in the project-specific review verification job definition
• in addition, the following JJB variables must be defined in the project-specific review verification job definition:
  • project-name (project identifier that can be freely chosen and is used in generated job names)
  • project (should correspond project's name in Gerrit)
  • stream (list of supported branches)
  • mvn-settings
    
    • should be named as '<project-name>-settings'
    • note that you may have to ask to add support for your '<project-name>-settings' in Jenkins Sandbox separately from LF you intend to test the job there
• The project must support CSIT as follows:
  • The project must have csit/run-project-csit.sh that is responsible of the entire CSIT execution
    • run-project-csit.sh must return exit code 0 on success and non-zero code on any failure - this is how the success/failure of the test suite(s) and +1/-1 verification vote is communicated to gerrit
    • currently run-project-csit.sh must provide robot test results or the entire review verification fails
      • A more generic basic template that allows other test frameworks should be added
  • The setup scripts must be able to use locally built docker images
    • preferably the images should be tagged and referred to unambiguously so there is no risk of them being pulled from Nexus3
• Following the integration/csit subdirectory structure and using its run-csit.sh (by cloning the integration/csit and copying the common scripts to workspace) is possible but not mandatory
• the csit subdirectory should also contain README.md that explains how to build the relevant docker images locally and run the CSIT with them

• The project must define a merge verification job based on one of "{project-name}-merge-verification-<artifact type>-{stream}

...

• " templates (which are defined in ci-management/jjb/integration/integration-templates-csit.yaml)
  • Same requirements apply for merge verification job definition as for review verification job

Example projects

There are a handful of projects and repositories that are already applying this design:

• ccsdk/integration
• ccsdk/oran
• cps
• dmaap/buscontroller
• optf/has
• optf/odf

CPS

This is the first project to create their functional tests directly under their own repository instead of moving them from integration/csit

...

• All the related job and template definitions done to ci-management repository are available in master
  • ci-management/jjb/cps/

...

• The actual staging script is specific to the project and has to be specified in the specific docker build job definition

• • 
    
    • cps-csit.yaml
  •  ci-management/jjb/integration/
    • integration-templates-csit.yaml
    • integration-macros.yaml
• The changes to cps repository itself are available under https://gerrit.onap.org/r/admin/repos/cps
  
  • the entire cps/csit subdirectory (actual tests)
  • cps-application/pom.xml (for docker image build)
  • cps/docker-compose/docker-compose.yml (for docker image startup)
• CPS also has some further elaboration on their CSIT under the following links:
  • https://lf-onap.atlassian.net/wiki/display/DW/CPS-188+CSIT+Testing+for+CPS
  • https://lf-onap.atlassian.net/wiki/display/DW/CPS+Developers+Team+Meeting+Recordings
  • Note though that the above links are already partially obsolete; for example, at the time of their creation the example project was still ccsdk/integration rather than cps

Open questions and remaining tasks

• Use of Robot framework is currently mandatory - this should be improved
• Should CSIT be able to test docker images from Nexus? If so, under which circumstances and for what purpose?
• Currently there are verification templates available only for maven artifact type - others (for example golang) may have to be added
• This proposal replaces plain Maven/Makefile/other artifact build jobs completely
  • Sonar builds seem to be completely separate scheduled builds anyway, and unsupported by any global templates?
  • Ideally all reviews should start with Sonar build and fail the review on violations