Releasing initial version for a new ONAP release
When releasing CCSDK artifact versions, there are some special considerations to bear in mind:
- There is a known issue in the Sonatype Nexus staging feature such that it only indexes the FIRST version of a zip or tarball that is created - not the most recent. For example, suppose that the current version is 0.2.3-SNAPSHOT, and thus the version built if you do a "release" build (either due to daily builds or due to posting the comment "please release") is 0.2.3. If you request version 0.2.3 of an installation zip stored in staging, it will not get you the NEWEST 0.2.3, but rather will get the OLDEST 0.2.3. To work around this, we add the suffix "-STAGING" to the release version during development, and only remove it when creating a release build. This guarantees that the release version will be consistent, since we will create only one release version.
- The CCSDK parent poms contain properties that specify the current version of each CCSDK sli repository. Unfortunately, this means that if any CCSDK repository has to be released, the CCSDK parent pom and all 4 CCSDK sli repositories need to be released - meaning their versions also have to be rolled.
The following is the procedure that must be followed to release new versions of CCSDK artifacts:
...
- Update version.properties to remove -STAGING tag. Update ccsdk versions within parent poms to the release version. Update single-feature-parent to disable SingleFeatureTest by setting property skip.karaf.featureTest to true. Submit change and, after merge build completes, do a release build by posting "please release" as comment.
- Roll to next snapshot version. Restore the -STAGING tag to version.properties, and update ccsdk versions within parent poms to the next snapshot version.
...
- Update version.properties to remove -STAGING tag and update pom.xmls to use released version of parent poms just created. Submit change and, after merge build completes, do a release build by posting "please release" as comment.
- Roll to next snapshot version. Restore the -STAGING tag to version.properties, and update versions of parent poms to the next snapshot version.
...
- Update pom.xmls to use newly created release version of parent pom and remove -STAGING tag from version.properties. Do a release build.
- Roll to next snapshot version. Restore the -STAGING tag to version.properties, and update versions of parent poms to the next snapshot version.
...
- Update pom.xmls to use newly created release version of parent pom and remove -STAGING tag from version.properties. Do a release build.
- Roll to next snapshot version. Restore the -STAGING tag to version.properties, and update versions of parent poms to the next snapshot version.
...
- Update pom.xmls to use newly created release version of parent pom and remove -STAGING tag from version.properties. Do a release build.
- Roll to next snapshot version. Restore the -STAGING tag to version.properties, and update versions of parent poms to the next snapshot version.
...
initial versions for a new ONAP release, we must release ALL CCSDK repositories, in the following order:
- Release maven artifacts for CCSDK parent poms (ccsdk/parent repository)
- Release maven artifacts for ccsdk/sli/core repository
- Release maven artifacts for the following repositories:
- ccsdk/sli/adaptors
- ccsdk/sli/northbound
- ccsdk/sli/plugins
- ccsdk/features
- ccsdk/oran
- Release maven artifacts for ccsdk/distribution
- Release docker containers for ccsdk/distribution
Releasing maven artifacts
To release maven artifacts for a CCSDK repository:
- Create a new staging version, if one does not already exist:
- In gerrit, find the most recent closed review for the repo in the branch you are using. For example, to find the most recent closed review in the master branch for ccsdk/parent, search would be "is:closed project:ccsdk/parent branch:master"
- Post the comment "stage-release" to the most recently merged change.
- Use the self release process to release maven artifacts (see Self Releases Workflow (Nexus2)). To do this:
- Create releases/{version}.yaml (e.g. by copying a existing file in that directory to a new one named for the release you are about to build).
- Edit the following fields in the yaml:
- Change "version" to the version you want to build. Note: that version must match the version created in the staging build in step 1.
- Change "log_dir" to match the Jenkins job for the staging build that was run in step 1.
- For repositories WITHOUT docker containers only - roll all your poms to the next snapshot version. You can do this easily using the script "changeVersion.sh" provided in ccsdk/parent/tools. For example, to change version to 2.1.1-SNAPSHOT, change directory to the top most level of the repository and run changeVersion.sh as follows:
changeVersion.sh 2.1.1-SNAPSHOT - Push your changes as a code review:
git add .
git commit -as -m "Review comment ...."
git review
These steps will create a gerrit review that, once merged, will cause the maven artifacts in the specified staging version to be released. An example of such a gerrit review is here
Special considerations for ccsdk/parent releases
Before releasing the ccsdk/parent, be sure to check the following files to verify the version property settings for the ccsdk repositories (e.g. ccsdk.sli.core.version):
- ccsdk/parent/oparent/pom.xml
- ccsdk/parent/odlparent/setup/src/main/resources/pom-template.xml
- ccsdk/parent/springboot/springboot-setup/src/main/resources/pom-template.xml
If you change any versions there, be sure to do a local build and push all changes (since odlparent and springboot pom.xmls are generated on the fly from the pom-template.xml files).
After releasing ccsdk/parent, please check the other ccsdk repositories to verify that none of the repositories are using the snapshot version you just released. If they are, then please update the repo(s) in question to use the version of ccsdk/parents you just released. You can make this change using the script updParentVersion.sh in ccsdk/parent/tools. For example, to change to version 2.1.0, you would run the following from the top level directory of the repo to be changed:
updParentVersion.sh . 2.1.0
Special considerations for ccsdk/distribution releases.
Before releasing ccsdk/distribution, be sure to check the versions in ccsdk/distribution/odlsli/odlsli-alpine/pom.xml to make sure you are using the correct released versions of maven artifacts.
Releasing docker containers
To release docker containers for ccsdk/distribution, first follow the steps above to release maven artifacts for this repository. Once that is complete, docker containers can be released via the self release process (see Self Releases Workflow (Nexus3 - Docker)) by the following steps:
- Create releases/{version}-container.yaml (e.g. by copying a existing file in that directory to a new one named for the release you are about to build).
- Edit the following fields in the yaml:
- Change "version" to the version you want to build. Note: that version must match the version created in the docker staging build.
- Change "log_dir" to match the Jenkins job for the docker staging build you want to release.
- Change "ref" to match the revision id for this change. To find this value, open the console log for the docker staging job above. Search for the string "Checking Out Revision" to find this hexadecimal value. For example:
Checking out Revision cf6fa2203af1f9f161029f2e93a5f19bb18c84af (refs/remotes/origin/guilin) - Verify the list of containers to be released. For each container, update the version to the correct timestamped version to be released. You can find this by searching for the string <release>-STAGING (e.g. 2.1.1-STAGING) in the console log for the staging job.
- Change "version" to the version you want to build. Note: that version must match the version created in the docker staging build.
- Roll all your poms to the next snapshot version. You can do this easily using the script "changeVersion.sh" provided in ccsdk/parent/tools. For example, to change version to 2.1.1-SNAPSHOT, change directory to the top most level of the repository and run changeVersion.sh as follows:
changeVersion.sh 2.1.1-SNAPSHOT - Push your changes as a code review:
git add .
git commit -as -m "Review comment ...."
git review
These steps will create a gerrit review that, once merged, will cause the maven artifacts in the specified staging version to be released. An example of such a gerrit review is here
Timing considerations
It is important to remember that maven artifacts and docker containers MUST be released in separate reviews. Do not try to combine these into the same review. Also, always make sure that the release-merge job for maven artifacts completes successfully before merging the review to release docker containers to avoid conflicts (both jobs trigger the same Jenkins job, and therefore share a workspace directory).