| Table of Contents |
|---|
Deliver Release Artifacts
Way of Working in Gerrit
...
Ensure all commits are using related TOPIC (one topic for one artifact)
...
Add "Release Process Step #' to each commit message (first line)
...
Scope
...
Action
...
Results
...
Examples
...
Update release notes
Note. Check documentation configuration and release instructions on: Create documentation for an ONAP release (ONAP project teams)
Note. Also update the openapi info.version property with the version we are releasing for cps-core , NCMP and NCMP-inventory openapi yaml files and onap-dmi-plugin repo.
...
Release notes available on https://docs.onap.org/projects/onap-cps/en/latest/release-notes.html
...
Just double check during release creation if the latest changes are committed.
cps-and-ncmp openapi.yaml
| Code Block |
|---|
cps-rest/target/generated-sources/openapi/openapi.yaml → docs/api/swagger/cps/openapi.yaml
cps-ncmp-rest/target/generated-sources/openapi/openapi.yaml → docs/api/swagger/ncmp/openapi.yaml
cps-ncmp-rest/target/generated-sources/openapi/openapi-inventory.yaml → docs/api/swagger/ncmp/openapi-inventory.yaml |
onap-dmi-plugin openapi.yaml
...
| Table of Contents |
|---|
Deliver Release Artifacts
Way of Working in Gerrit
Ensure all commits are using related TOPIC (one topic for one artifact)
Add "Release Process Step #' to each commit message (first line)
Example:
Reference commits for cps-ncmp : https://gerrit.onap.org/r/q/topic:CPS-2488
Reference commits for onap-dmi-plugin : https://gerrit.onap.org/r/q/topic:CPS-2489
Scope | Action | Results | Examples | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Any Release | Update release notes Note. Also update the openapi info.version property with the version we are releasing for cps-core , NCMP and NCMP-inventory openapi yaml files and onap-dmi-plugin repo. | Release notes available on https://docs.onap.org/projects/onap-cps/en/latest/release-notes.html | cps-and-ncmp onap-dmi-plugin | ||||||||||||
| 2 | Update read-the-docs copies of openapi documentation e.g. for CPS-Core, NCMP and ONAP-DMI-PLUGIN. Just double check during release creation if the latest changes are committed. cps-and-ncmp openapi.yaml
Note 1. Run Note 2. This step can be skipped if there are no OPEN API changes | Latest (amalgamated) openapi.yaml available in read-the-docs | 3 | For DMI Plugin and update any CPS Core release dependency, if needed:
| Changes | 4 | Go to latest Gerrit merged review of repo and comment 'stage-release' | |||||||||
| 5 | Add and merge 'x.y.z.yaml' file to releases folder of the repository root. It describes the release and refers to maven-stage job previously ran. Note. this file should NOT contain 'tag_release=false' | Maven artifacts are published to maven release repository |
| |||||||||||||
| 6 |
| Code Block |
|---|
container_release_tag: '1.1.0'
...
...
containers:
- name: 'cps-and-ncmp'
version: '1.1.0-SNAPSHOT-20210609T102555Z' |
Docker image is published to docker release repository
Change 124887
To get the 'version' for the YAML file you should look up the full console log of the cps-maven-docker-stage-master job from step 4 and search for : 'Built image to Docker daemon as nexus3.onap.org:10003/onap/cps-and-ncmp'. Then you will find the correct version number with the timestamp.
Prepare the next drop by bumping patch version (3rd digit)
Update all pom files; set to x.y.z-SNAPSHOT by running "mvn versions:set -DnewVersion=<snapshot version>"
In \version.properties, set to x.y.z
Add section in \docs\release-notes.rst for next release
Change 124888
Once versions are bumped update the docker-compose file and update the latest images
cps-core : docker-compose.yaml
ncmp-dmi-plugin: docker-compose.yaml
/cps/openapi.yaml
cps-ncmp-rest/target/generated-sources/openapi/openapi.yaml → docs/api/swagger/ncmp/openapi.yaml
cps-ncmp-rest/target/generated-sources/openapi/openapi-inventory.yaml → docs/api/swagger/ncmp/openapi-inventory.yaml |
onap-dmi-plugin openapi.yaml
| Code Block |
|---|
target/generated-sources/openapi/openapi/openapi.yaml → docs/api/swagger/openapi.yaml |
Note 1. Run mvn clean install locally first to get required files in target subfolders
Note 2. This step can be skipped if there are no OPEN API changes
Latest (amalgamated) openapi.yaml available in read-the-docs
For DMI Plugin and update any CPS Core release dependency, if needed:
ncmp-dmi-plugin/pom.xml (cps.version property)
Note : This step to be only done when creating release of onap-dmi-plugin
onap-dmi-plugin
Go to latest Gerrit merged review of repo and comment 'stage-release'
cps-and-ncmp
https://gerrit.onap.org/r/c/cps/+/139476
Job maven-stage-master https://jenkins.onap.org/job/cps-maven-stage-master/956/
Job maven-docker-stage-master https://jenkins.onap.org/job/cps-maven-docker-stage-master/948/
onap-dmi-plugin
https://gerrit.onap.org/r/c/cps/ncmp-dmi-plugin/+/139619
Job maven-stage-master
https://jenkins.onap.org/job/cps-ncmp-dmi-plugin-maven-stage-master/702/
Job maven-docker-stage-master
https://jenkins.onap.org/job/cps-ncmp-dmi-plugin-maven-docker-stage-master/702/
Add and merge 'x.y.z.yaml' file to releases folder of the repository root.
It describes the release and refers to maven-stage job previously ran.
Note. this file should NOT contain 'tag_release=false'
Maven artifacts are published to maven release repository
cps-and-ncmp:
https://gerrit.onap.org/r/c/cps/+/139615
onap-dmi-plugin:
Add and merge 'x.y.z-container.yaml' file to releases folder of the repository root.
It describes the release and refers to maven-docker-stage job previously ran.
Set "ref" to the (full) SHA of the last git commit or the commit of the stage release
Note opinions difference what commit it should be exactly , fact is the ref. value is for '(future) reference only' The process will complete either way and which commit exactly is bring referred too is quiet moot (not important)
Take the latest built image, retag it without the timestamp :
e.g. SO release file
| Code Block |
|---|
container_release_tag: '1.1.0'
...
...
containers:
- name: 'cps-and-ncmp'
version: '1.1.0-SNAPSHOT-20210609T102555Z' |
Docker image is published to docker release repository
cps-and-ncmp:
https://gerrit.onap.org/r/c/cps/+/139616
onap-dmi-plugin
https://gerrit.onap.org/r/c/cps/ncmp-dmi-plugin/+/139622
Note : To get the 'version' for the YAML file you should look up the full console log of the cps-maven-docker-stage-master job from step 4 and search for : 'Built image to Docker daemon as nexus3.onap.org:10003/onap/cps-and-ncmp'. Then you will find the correct version number with the timestamp.
Prepare the next drop by bumping patch version (3rd digit)
Update all pom files; set to x.y.z-SNAPSHOT by running "mvn versions:set -DnewVersion=<snapshot version>"
In \version.properties, set to x.y.z
Add section in \docs\release-notes.rst for next release
cps-and-ncmp
https://gerrit.onap.org/r/c/cps/+/139617
onap-dmi-plugin
https://gerrit.onap.org/r/c/cps/ncmp-dmi-plugin/+/139624
Once versions are bumped update the docker-compose file and update the latest images
cps-core : docker-compose.yaml
ncmp-dmi-plugin: docker-compose.yaml
Update https://gerrit.onap.org/r/q/project:oom with the release specific changes:
Note. Use [CPS] prefix for OOM commit message
Update /kubernetes/cps/values.yaml with new image versions
Update /kubernetes/cps/resources/config/application.yml if properties need to be added or updated.
Before pushing changes to the release-specific OOM branch, it is required to push them to master first. If it can not be done, then specify a reason in the release-specific change (for example, image version number is branch specific and it is expected that it could be different in master branch and release branch).
Note : OOM updates can be delegated to the team which uses it. We at EST are currently not using OOM hence not maintaining it.
Only when Branching
Create the (previous) release branch in Gerrit for the version you are releasing e.g. 'istanbul'.
Has to be done manually (e.g. here: https://gerrit.onap.org/r/admin/q/project:oom with the release specific changes:
Note. Use [CPS] prefix for OOM commit message
Update /kubernetes/cps/values.yaml with new image versions
Update /kubernetes/cps/resources/config/application.yml if properties need to be added or updated.
Before pushing changes to the release-specific OOM branch, it is required to push them to master first. If it can not be done, then specify a reason in the release-specific change (for example, image version number is branch specific and it is expected that it could be different in master branch and release branch).
Only when Branching
Create the (previous) release branch in Gerrit for the version you are releasing e.g. 'istanbul'.
Has to be done manually (e.g. here: https://gerrit.onap.org/r/admin/repos/cps,branches) by users with committer rights.
Note : The branch is created in ONAP gerrit. After sync happens the branch is available in NORDIX for Step-13.repos/cps,branches) by users with committer rights.
Note : The branch is created in ONAP gerrit. After sync happens the branch is available in NORDIX for Step-13.
Sync happens by a scheduled job , but we can request infra team to trigger it forcefully.
In ci-management repo, configure new Jenkins jobs for the release branch by adding a new release stream to the project. e.g. https://gerrit.onap.org/r/c/ci-management/+/118868/1/jjb/cps/cps.yaml
Jobs for cps-and-ncmp and onap-dmi-plugin
https://gerrit.onap.org/r/c/ci-management/+/139627
On Master branch increase Minor version of Master branch (2nd digit)
In pom files, set to x.y.z-SNAPSHOT by running "mvn versions:set -DnewVersion=<snapshot version>"
In version.properties, set to x.y.z
cps-and-ncmp
https://gerrit.onap.org/r/adminc/cps/repos+/cps,branches
Change 124942
In ci-management repo, configure new Jenkins jobs for the release branch by adding a new release stream to the project. e.g. 139629
onap-dmi-plugin
https://gerrit.onap.org/r/c/ci-management/+/118868/1/jjb/cps/cps.yaml
Change 125006
Topic CPS-728 (note step numbering has changed)
On Master branch increase Minor version of Master branch (2nd digit)
In pom files, set to x.y.z-SNAPSHOT by running "mvn versions:set -DnewVersion=<snapshot version>"
In version.properties, set to x.y.z
Change 124943
Topic CPS-728 (note step numbering can have changed)
On (previous) release (e.g. istanbul) branch:
update ".gitreview" (change "defaultbranch" value)
On (previous) release (e.g. oslo) branch:
update ".gitreview" (change "defaultbranch" value)
cps-and-ncmp
https://gerrit.onap.org/r/c/cps/+/139634
onap-dmi-plugin
https://gerrit.onap.org/r/c/cps/ncmp-dmi-plugin/+/139635
Note : Make sure you are on the previous release branch in order to do these changes.
Steps to Deliver Release Patches
Decide with team if a bug should be dropped back to previous release or not, consider things like (use fix-version field in Jira to indicate this)
bug was reported by user of previous release (easy decision
)bug exposes behavior that was not in line with acceptance criteria for a user story that was delivered in previous release
Make the fix and have it merged in master branch
use minimal code to avoid merge/drop back issues
specific test for bug fix should be included where possible
Cherry pick the fix from master branch to release branch
From Gerrit:
Navigate to ... / Cherry Pick
Fill the form with the release branch name (honolulu) in "Cherry Pick to branch" field and click "Cherry Pick"
Using local branch (to resolve cherry-pick conflicts):
Create local branch from honolulu (create branch & switch to branch)
Cherry-pick commit from master branch
Resolve conflicts
Continue cherry-pick (git cherry-pick --continue)
git push origin HEAD:refs/for/honolulu (or git review)
Review patch by peers as normal
Ensure that Gerrit merge requests both in master and release branches have the same Change-Id value (ex: https://gerrit.onap.org/r/q/Ia58a8dfcf427e373b24bb3be7436abf6abd55492). Then, related fixes can be easily filtered and clicking on the Change-Id from one change provides the list of all related ones.
Update Release version in a separate commit if and when required
A few bugs can be combined in one patch.
Release notes doc should be updated too
Typically only the 'patch' number (last digit) should be increased. See alsoOnce the fix is in release branch, deliver releases artifacts from release branch as described in previous section.
...