Versions Compared

Key

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

...

Drawio
bordertrue
diagramNameReview and merge verification flows with project-specific CSIT
simpleViewerfalse
width
linksauto
tbstyletop
lboxtrue
diagramWidth16441424
revision1011

  1. Developer pushes a commit to Gerrit
  2. Gerrit triggers review verification job in Jenkins
    • The templates for review verification job are in ci-management/jjb/integration/integration-templates-csit.yaml, named as "{project-name}-review-verification-<artifact type>-{stream}"
      • 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
    • 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
  3. Docker build is started
  4. 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 differentiate local image from any that could be found from Nexus3
      • Missing repository prefix in the image name is an obvious hint 
  5. 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
  6. 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?
  7. Review verification job gives +1 or -1 verify vote to the review based on the overall success of the verification
  8. Once the commit is approved (+2'd) and submitted, Gerrit triggers merge verification job in Jenkins
    • The template for merge verification job is in ci-management/jjb/integration/integration-templates-csit.yaml and currently named as "{project-name}-merge-verification-<artifact type>-{stream}
    • 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
    • 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
  9. Docker build is started
  10. Docker build step builds docker image(s) to local temporary docker repository
    • The docker build scripts and the created artifacts are completely based on master
    • The actual build script is the same as in review verification and used in the same way
  11. CSIT is started in exactly the same way as review verification
  12. CSIT job pulls the docker images created in step 10. (by using project-specific setup scripts) and tests them
  13. Execution moves to staging steps after successful CSIT
  14. Artifact staging step pushes the artifacts to Nexus2 staging repository
    • ...if there is any actual need for this step? What are the staged artifacts actually used for (and where and how)?
  15. Docker image staging step tags the docker images(s) with <version>-STAGING-latest
  16. ...and pushes them to ONAP Nexus3
  17. should that be staging or snapshot?

Requirements and recommendations

...

  • 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 following JJB variables must be defined in the project definition that defines the review verification job:
    • project-name (project identifier that can be freely chosen)
    • project (should correspond project's name in Gerrit)
    • stream (list of supported branches)
    • java-version
    • mvn-version
    • mvn-settings
    • mvn-global-settings
  • The project must support CSIT as follows:
    • The project must have csit/run-project-csit.sh that is responsible of the entire CSIT execution
    • The setup scripts should be able to use locally built docker images
    • 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 project should 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)The project should define a script for tagging verified local docker images as STAGINGThe project-specific verification job definitions must specify the project-specific script or method that
  • tags the local, verified docker image(s) with <version>-STAGING-latest
  • pushes the docker image(s) to ONAP Nexus3

Example project

CCSDK/distribution

...