LF has mandated teams to migrate to use global-jjb template (required by 07/19). Need to consistent approach to migrate all dcae components and also update all JJB definition across DCAE components to use consistent template and build setup.

Below notes from LF-RELENG team.

Ready to migrate? Things to consider and challenges faced with the currently migrated teams

• The job we are migrating to can be found in global-jjb: 
  • Maven releases: https://github.com/lfit/releng-global-jjb/blob/master/jjb/lf-maven-jobs.yaml#L799
  • Docker releases built with maven artifacts: https://github.com/lfit/releng-global-jjb/blob/master/jjb/lf-maven-jobs.yaml#L975
• These jobs are being designed to eventually automate the release process without LF intervention.
• gerrit-maven-stage jobs incude a step to automatically sign the artifacts using SIGUL:
  • Currently, SIGUL only works in CentOS for which the teams will need to use these nodes for running their builds
  • If the team has a special dependency on Ubuntu, please inform LFRELENG before the migration so that we disable SIGUL signing for that project in particular. 
• gerrit-maven-stage enforces depenendcies exclusively on released versions. Please do not use dependnecies on snapshot artifacts
• Development MUST happen on a snapshot version of the artifact. Team daily development must be done on top of snapshots. 
  • Failing to do so will cause the jobs to fail since gerrit-maven-stage is designed to produce a new release candidate out of a snapshot version.
• gerrit-maven-stage and gerrit-maven-docker-stage support versions plugin. The team can decide to use it or skip it to bump their versions.
•  gerrit-maven-stage and gerrit-maven-docker-stage produce a patchset that is ready for the tech teams to use to commit their release candidate details. Please use it.
  • For example:https://logs.onap.org/production/vex-yul-ecomp-jenkins-1/modeling-genericparser-maven-stage-master/4/patches/

Changes needed to be done and stakeholders

TECHTEAM: Verify that the previous section's concerns listed above are not a concern to the tech team.

TECHTEAM: If the project's pom.xml has a dependency on Oparent, they need to migrate to version 2.0.0. For example: https://gerrit.onap.org/r/#/c/modeling/toscaparsers/+/88216/

TECHTEAM: Make sure there is no usage of nexus-staging-maven-plugin in pom.xml. For example: https://gerrit.onap.org/r/#/c/clamp/+/87812/

LFRELENG: Add the team's needed jobs from global-jjb. For example: https://gerrit.onap.org/r/#/c/ci-management/+/77825/

TECHTEAM + LFRELENG: Verify the new jobs are running fine and deploying the correct artifacts.

LFRELENG: Cleanup old un needed jobs. For example: https://gerrit.onap.org/r/#/c/ci-management/+/87495/

Testing the migration

• The migration cannot be tested in the Sandbox unfortunatelly.
  • The Sandbox is specifically designed to block Nexus2 pushes and we will not be able to confirm if the artifacts were pushed correctly.
  • The migration changes depend on pom.xml file changes in the source code which cannot be tested unless these changes are merged.
• Please notice that we can't keep both version-java-daily (and similar local templates) and gerrit-maven-stage (from global-jjb) running successfully at the same time.
  • The plugin in question  "nexus-staging-maven-plugin" only works for the old templates and, once we remove it's usage to be able to migrate, it will cause the old jobs to fail.

Reference - https://wiki.onap.org/display/DW/global-jjb+Migration+Tracker