...
When tagging for a release, the following commands should can be used:
| Code Block |
|---|
git tag -sm "7.0.0-ONAP Release" 7.0.0-ONAP <optional-commit-id> git push <remote-name>origin 7.0.0-ONAP |
Most likely you will need 'gpg2' installed and configured for git in order to sign the tags. NOTE: ONAP is requiring that the tags be signed.
Release tags are best to be applied against the last commit that was for an image release. However, sometimes that does not apply if an image did not require a new release. So its possible some tags will be on the same commit across releases (eg policy/docker is one repo where that is true). Depending on when branching happens, some tags may not be visible in a log for a specific branch. Best to use the online gerrit gui to see all the tags for a repo.
Steps for Releasing and branching |
|---|
Raise a review to refer released version of dependency (parent, common, models etc.) |
| Go to latest merged review of repo and comment “stage-release” |
It will trigger 2 Jenkins jobs - stage-master & docker-stage-master NOTE: The "docker-stage-master" job will fail for drools-applications |
Once the jobs are successful, create a yaml file for releasing maven artifacts first and raise a review. This file can typically be generated using this script: mkart.sh |
Once that is merged and build is successful, create another container.yaml file for releasing docker image and raise a review. This file can typically be generated using this script: mkdock.sh NOTE: Drools-applications will require a 2nd "stage-release" to be done due to the way it is built; the docker image requires the java artifacts to be released first, which are packaged into the image. |
| Once that is merged and build is successful, go to nexus3.onap.org & nexus.onap.org and verify that the image & artifacts were released |
Bump the snapshot version to next patch version and raise a review - Use this command “mvn versions:set -DnewVersion=<snapshot-version>” Update the patch version in "version.properties" file. |
| Below steps are ONLY needed when we are branching and proceeding to new release |
| Once that is merged and build is successful, go to gerrit and create a “guilin” branch. |
Once the branch is created, bump the master branch to next minor version using the same maven command and raise a review |
| Finally go to guilin branch and change the .gitreview file to point to guilin as default branch and raise the review. |
...