Content Comparison

...

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:
%22CPS
CPS-
728%22

...

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. 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

Change 123658

cps-and-ncmp
https://gerrit.onap.org/r/c/cps/+/139476

onap-dmi-plugin
https://gerrit.onap.org/r/c/cps/ncmp-dmi-plugin/+/139618

2

Update read-the-docs copies of openapi documentation e.g. for CPS-Core, NCMP and ONAP-DMI-PLUGIN.

Note :

Code Blocktitlecopy

We have configured a plugin which takes care of copying the generated openapi spec files from the target directory to the docs folder. So no manual intervention needed.

Just double check during release creation if the latest changes are committed.

cps-and-ncmp openapi.yaml

Code Block
cps-rest/target/generated-sources/

swagger

openapi/openapi.yaml → docs/api/swagger/cps/openapi.yaml
cps-ncmp-rest/target/generated-sources/

swagger

openapi/openapi.yaml → docs/api/swagger/ncmp/openapi.yaml
cps-ncmp-rest/target/generated-sources/

swagger Code Blocktitlecopy

openapi/openapi-inventory.yaml → docs/api/swagger/ncmp/openapi-inventory.yaml

For DMI-Plugin:

onap-dmi-plugin openapi.yaml

Code Block
target/generated-sources/openapi/

swagger

openapi/openapi.yaml → docs/api/swagger/openapi.yaml

For CPS Temporal (no need to run mvn build for this one):

Code Block

title	copy openapi.yml

openapi/swagger/openapi.yml → docs/_static/openapi/swagger/openapi.yml

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

3

For

CPS Temporal and

DMI Plugin

,

and update any CPS Core release dependency, if needed:

cps

ncmp-dmi-

temporalncmp

plugin/pom.xml (cps.version property)

cps-temporal/csit/plans/default/setup.sh (STABLE_CPS_CORE_VERSION environment variable to use for integration testing)

Note : This step to be only done when creating release of onap-dmi-plugin

onap-dmi-plugin

/pom.xml

Changes

127857 (cps-temporal)

127858 (dmi-plugin)

https://gerrit.onap.org/r/c/cps/ncmp-dmi-plugin/+/139630

4

Go to latest Gerrit merged review of repo

and comment

and comment 'stage-release'

maven-stage Jenkins job is triggered
maven-docker-stage Jenkins job is triggered
Maven artifacts are published to Nexus 2 autorelease repository
Docker images are published to Nexus 3 registry

Change 124884

Job

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

145

/702/

Job maven-docker-stage-master

145

https://jenkins.onap.org/job/cps-ncmp-dmi-plugin-maven-docker-stage-master/702/

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 step is ignored for CPS Temporal (no Maven artifact delivered)

Note. this file should NOT contain 'tag_release=false'

Maven artifacts are published to maven release repository

Change 124882

Topic CPS-728

cps-and-ncmp:
https://gerrit.onap.org/r/c/cps/+/139615

onap-dmi-plugin:

https://gerrit.onap.org/r/c/cps/ncmp-dmi-plugin/+/139621

6

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

Change 124887

Topic CPS-728

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.

7

Prepare the next drop by bumping patch version (3rd digit)

In

Update all pom files

, 8

; set to x.y.z-SNAPSHOT by running "mvn versions:set -DnewVersion=<snapshot version>"
In \version.properties, set to x.y.z

Change 124888
Topic CPS-728

9

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

8

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

9

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).

Change 124893
Topic CPS-728

Note : OOM updates can be delegated to the team which uses it. We at EST are currently not using OOM hence not maintaining it.

10

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.
Sync happens by a scheduled job , but we can request infra team to trigger it forcefully.

https://gerrit.onap.org/r/admin/repos/cps,branches

10

11	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

Change 124942
Topic CPS-728 (note step numbering has changed)

11

On (previous) release (e.g. istanbul) branch:

update ".gitreview" (change "defaultbranch" value)

Change 124943:

Topic CPS-728 (note step numbering has changed)

Jobs for cps-and-ncmp and onap-dmi-plugin https://gerrit.onap.org/r/c/ci-management/+/139627
12	On Master branch

increase

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

Topic CPS-728 (note step numbering has changed)

125006:

cps-and-ncmp
https://gerrit.onap.org/r/c/cps/+/139629

onap-dmi-plugin
https://gerrit.onap.org/r/c/cps/ncmp-dmi-plugin/+/139630

13

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)
1. bug was reported by user of previous release (easy decision )
2. 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
1. use minimal code to avoid merge/drop back issues
2. specific test for bug fix should be included where possible
Cherry pick the fix from master branch to release branch
1. From Gerrit:
  1. Navigate to ... / Cherry Pick
  2. Fill the form with the release branch name (honolulu) in "Cherry Pick to branch" field and click "Cherry Pick"

...

1. 1. Image Added

...

1. 1. Image Added
2. Using local branch (to resolve cherry-pick conflicts):
  1. Create local branch from honolulu (create branch & switch to branch)
  2. Cherry-pick commit from master branch

...

1. 1. Resolve conflicts
  2. Continue cherry-pick (git cherry-pick --continue)
  3. git push origin HEAD:refs/for/honolulu (or git review)
Review patch by peers as normal
1. 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 also
1. Release Versioning Strategy (proposal for Honolulu)
2. ONAP API Common Versioning Strategy (CVS) Guidelines
Once the fix is in release branch, deliver releases artifacts from release branch as described in previous section.

Preparing for third party (stakeholder) testing of specific features before general (onap) release

Ensure a Jira is created and shared with stakeholder to track the required change
1. CPS Team might create dependent (blocking) Jira's link to the main Jira as required
Common Acceptance criteria:
1. latest RTD Design docs get update with relevant APIs (e.g. https://docs.onap.org/projects/onap-cps/en/latest/design.html)
2. latest RTD Release Note (new snapshot section) wil be updated with the delivered Jira (from step 1) (similar to https://docs.onap.org/projects/onap-cps/en/latest/release-notes.html#version-2-0-1)
3. CSIT test wil be updated/added to cover new functionality
4. Demo to stakeholder (this is

...

1. really the best sign it is -almost- done to the stakeholder)
Jira can be closed (stakeholder can subscribe to notifications about this)
Stakeholder team can take source and using their own preferred process build new images for testing

This does NOT include:

Version updates ie. CPS will only update version as is required for the ONAP release process
(Docker) image
buidling
building

Version	Old Version 73	New Version Current
Changes made by	Former user	Priyank Maheshwari
Saved on	Mar 18, 2022	Dec 18, 2024

Versions Compared

Key

Deliver Release Artifacts

Way of Working in Gerrit

cps-and-ncmp openapi.yaml

onap-dmi-plugin openapi.yaml

Steps to Deliver Release Patches

Preparing for third party (stakeholder) testing of specific features before general (onap) release

References