Page Comparison

Self releases are now possible after the migration to latest global-jjbs staging jobs

...

1. The tech team needs to make sure their committer list is up to date as these will be the people approved to make releases.
   
   1. The reason behind this, only committers can +2 and merge changes in their tech team repo.
   2. The releases merge job will be triggered by files merged in the repo and will execute a release.
2. Tech team needs to add "{project-name}-gerrit-release-jobs" to their ci-management yaml files. 
   1. This group introduces "gerrit-release-verify" and "gerrit-release-merge"
3. Once a release candidate is build using gerrit-maven-stage, a new file will be posted describing the release.
   
   1. This file needs to be located in the root repo under a "releases" folder.
   2. An example can be viewed here: https://github.com/lfit/releng-global-jjb/blob/master/docs/jjb/lf-release-jobs.rst 
      1. Name of the file should match the semantic version of the release being published. (For example: releases/1.0.0.yaml)
      2. distribution_type: 'maven'  (Future expansion will allow "container" to be provided"
      3. version: '#.#.#' (Release semantic version)
      4. project: 'project-name' (Project name, for example 'ccsdk-parent')
      5. log-dir: 'pointer_to_maven_stage_job/build_number/' (for example: 'ccsdk-parent-maven-stage-master/2/')
      6. maven_central_url: 'oss.sonatype.org' ( Optional, in case the team want's to publish to Maven Central)
4. This file will trigger "{project-name}-release-verify-{stream}"
   1. This job can also be triggered using the comment "recheck|reverify"
   2. The verify job will make sure the release file contains the needed information and that the candidate exists.
5. Tech team needs to +2 this new change and merge it. Please do not override any -1 Verify from Jenkins.
6. The merge will trigger "{project-name}-release-merge-{stream}"
   1. This job can also be triggered using the comment "remerge"
   2. This job will push the release and tag the repo.

After your self release ...

...

Once your self release file was merged and processed by "gerrit-release-verify" and "gerrit-release-merge"...

• Do not attempt to revert files in releases/  → Even if the release was not needed, we need to keep track on what happened in that repo also the tag needs to be kept in the repo
• Do not attempt to re-tag the repo with the same version → this will fail as the gerrit-release-merge job already tagged it
• Do not modify releases files → Once a releases file is merged, it is immediately processed. If the team needs to release a new build number, please bump your versions and generate another stage-release
• Do not re-use the same stage-release build number for multiple releases files → Once an autorelease package is pushed, it is closed and it cannot be re-released. 

...

• I found AAI's "Gizmo" example a bit more helpful than the example listed above, line item 3, because the above one isn't ONAP specific.  AAF's works now as well, if you want to look at that too.  Look in "ci-management/jjb/<project>"
• The new process assumes that you build your Docker Containers with Maven.  If you have some other method, you will need to get it to work with Maven.  I was able to by using Exec Plugin
• The normal "deploy" for Java Projects in Maven are Jars into Nexus.  Deploying into Docker, however, is a different artifact type altogether.  You can handle each one at the correct steps by using "Maven Profiles"... I created one just in my Docker Build Directory called "build-docker", and used the "exec" goal, which means I could do the following for Maven Params: " install -maven.test.skip exec:exec -Pdocker-build". (note, "Tests already performed twice before... why make this happen again?)
• Do make sure your Docker Build in Maven includes "docker push".  It's not enough to simply build the Docker image.  LF's Template will cover the Docker Login (they had to add the credentials in my case, once they did, it worked)
• Realize that LF's Template will convert all the Maven Jar Versions with "-SNAPSHOT" (i.e.2.1.15-SNAPSHOT) into it's release version.  Your Docker Build/Push needs to recognize this, even though the DOCKER VERSION generated has "-SNAPSHOT" in it.  What this means is that your Docker may have version 2.1.15-SNAPSHOT, while the jars copied in will be 2.1.15.  Your Docker Build command need to handle this.
• don't miss the "release" file above.  Lack of it caused maven to not run at all in my case.LATE BREAKING: Call me dense, but I didn't realize that it is the CREATION and SUBMITTING of the releases/<version>.yaml that actually triggers the self-release.  When you are going to a new version, i.e. "2.1.16", in my case, you need to REMOVE this file until you are actually ready to release.  I put a "HowToRelease.txt" file explaining this in my home directory, because I'm sure I'll forget.
• DO NOT BE DISCOURAGED!  If you keep cycling, reading the error outputs and pushing through, with LF's help, you'll make it!  (Thanks, Jess, Arin, Eric et al)