...
- 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)
Step | 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) | Release notes available on https://docs.onap.org/projects/onap-cps/en/latest/release-notes.html | |||
2 | Update read-the-docs copies of openapi documentation e.g. for CPS-Core:
|
|
|
For DMI-Plugin:
|
|
For CPS Temporal (no need to run mvn build for this one):
openapi/swagger/openapi.yml → docs/_static/openapi/swagger/openapi.yml
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 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 |
| ||
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. Take the latest built image, retag it without the timestamp : e.g. SO release file
| Docker image is published to docker release repository |
| ||
7 | Prepare the next drop by bumping patch version (3rd digit) |
|
|
| ||
8 | Once versions are bumped update the docker-compose file and update the latest images
| ||
---|---|---|---|
9 | Update https://gerrit.onap.org/r/q/project:oom with the release specific changes:
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). |
|
| ||||
10 | Only when Branching | Create the (previous) release branch in Gerrit for the version you are releasing e.g. 'istanbul'. Note : The branch is created in ONAP gerrit. After sync happens the branch is available in NORDIX for Step-13. | https://gerrit.onap.org/r/admin/repos/cps,branches |
---|
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 |
|
---|
|
On (previous) release (e.g. istanbul) branch:
- update ".gitreview" (change "defaultbranch" value)
- Change 124943:
- Topic CPS-728 (note step numbering has changed)
12 | On Master branch increase Minor version of Master branch (2nd digit)
|
|
---|
|
13 | On (previous) release (e.g. istanbul) branch:
|
|
---|
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
...
- Version updates ie. CPS will only update version as is required for the ONAP release process
- (Docker) image buidlingbuilding