...
| Warning |
|---|
With care an expert can start from an intermediate phase if repositories early in the release process such as policy/common or policy/models are not being released. To do this, the expert can carefully edit your local copy of the releasePhase.sh script and comment out the parts of each release phase that the expert does not want to execute. For example, if the expert wants to start from Phase 8 below (use the existing versions of policy/parent, policy/common, policy/docker, and policy/models), the expert can comment out the operation to update the policy/models snapshots and safely start from Phase 8. |
| Warning |
|---|
The getReleaseData.sh script, among other things, retrieves the repository tags from the repository being released from nordix gerrit. After a repo release has been carried out in a stage (reviews are merged etc), the tag for the release is automatically created in github. There can sometimes be a delay in propagating the tag to onap gerrit and then especially to nordix gerrit. This means that the tags will be unavailable for getReleaseData.sh to fetch. And thus, the pf_release_data.csv will NOT have the latest released tag. In this case, you MUST manually update the release number in the pf_release_data.csv file. For example, after stage 2, the parent latest version tag may not be in nordix yet. You will notice, after stage 2, when you run getReleaseData.sh, the line with policy/parent in the pf_release_data.csv file does not have the new version. So, you just update that line with the new version (no need to update the SNAPSHOT version) - and then continue with stage 3. |
Running a Release
In each phase run getReleaseData.sh followed by releasePhase.sh.
...
- In Gerrit, create the new branch off the master branch in each repository
- Check that all the branches have been created correctly
On the master branch, run the getReleaseData.sh script to update the pf_release_data.csv file
Code Block language bash getReleaseData.sh -l onap
Run the newReleaseSnapshots.sh script to update the snapshot versions on all the repositories and merge the generated commits
For a minor release run the script as follows:follows:
Code Block language bash newReleaseSnapshots.sh -l onap -i POLICY-112911For a major release run the script with the -m flag as follows:
Code Block language bash newReleaseSnapshots.sh -m -l onap -i POLICY-112911
Run the resolveRefs.sh script to update the cross references and base docker images, then merge the generated commits
newReleaseSnapshotsCode Block language bash resolveRefs.sh -l onap -i POLICY-112911
For a major release run the script with the -m flag as follows:
Code Block language bash newReleaseSnapshots.sh -m -l onap -i POLICY-112911Run the resolveRefs.sh script to update the cross references and base docker images, then merge the generated commits
Code Block language bash - Add the new branch to the JJB job Yaml files in onap/ci-management/jjb/policy so that the Jenkins jobs for the new branch are created.
- Check out the release branch into a separate tree structure:
release_name/policy/parent
release_name/policy/common
etc. - On the release branch, edit the file release_name/policy/parent/docs/conf.py and change all references to master or latest to your release name (these variables are release, version and branch)
- On the release branch, edit the .gitreview file and change the line defaultbranch=master to defaultbranch=<release_name>, where <release_name> is the name of the new release
- Raise commits and merge the changes in 7. and 8. above.
The snapshot versions and references are now set correctly on the master branch for and the next release branch.
Example of Performing a Release
...