...
- Ensure all commits are using related TOPIC (one topic for one artifact)
- Add "Release Process Step #' to each commit message (first line)
- Example:
https://gerrit.onap.org/r/q/topic:CPS-2220(NEW)
https://gerrit.onap.org/r/q/topic:%22CPS-728%22 (OLD)
/cps-rest/target/generated-sources/ |
|
swagger/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/ |
|
swaggeropenapi/openapi-inventory.yaml → |
|
/docs/api/swagger/ncmp/openapi-inventory.yaml |
For DMI-Plugin: |
ncmp-dmi-plugin/src/target/generated-sources/openapi/ |
|
swaggeropenapi/openapi.yaml → docs/ |
|
docsopenapiNote 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 DMI Plugin and update any CPS Core release dependency, if needed: - ncmp-dmi-plugin/pom.xml (cps.version property)
|
| Changes |
---|
4 | Go to latest Gerrit merged review of repo 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 maven-stage-master 145
- Job maven-docker-stage-master 145
|
---|
4
|
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 | |
---|
56 | 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 | |
---|
6- 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 , - ; 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
|
| |
7 |
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). |
| |
---|
89 124942On 10 | On (previous) release (e.g. istanbul) branch: - update ".gitreview" (change "defaultbranch" value)
| | 11 | 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
|
| |
has 125006: |
13 | On (previous) release (e.g. istanbul) branch: - update ".gitreview" (change "defaultbranch" value)
|
| |
---|
Steps to Deliver Release Patches
...
- Ensure a Jira is created and shared with stakeholder to track the required change
- CPS Team might create dependent (blocking) Jira's link to the main Jira as required
- Common Acceptance criteria:
- latest RTD Design docs get update with relevant APIs (e.g. https://docs.onap.org/projects/onap-cps/en/latest/design.html)
- 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)
- CSIT test wil be updated/added to cover new functionality
- Demo to stakeholder (this is realy 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 building
References