How to Release

Maintenance Releases:

(Using F-Maintenance release as an example here)

Overall Steps

• Cherrypick & release as below (More details below)
• Update image version numbers on release wikipages, e.g. in:
  • https://lf-o-ran-sc.atlassian.net/wiki/display/RICNR/Image+names+and+tags
  • https://lf-o-ran-sc.atlassian.net/wiki/pages/viewpage.action?pageId=14516612
  • https://lf-o-ran-sc.atlassian.net/wiki/display/RICNR/Release+F+-+Run+in+Docker#ReleaseFRuninDocker-Images
• Check version numbers used in documentation
  • RTD, WIKI, ReadMe’s,
  • E.g. https://lf-o-ran-sc.atlassian.net/wiki/display/RICNR/Release+F+-+Run+in+Docker
• Update versions in tests
• Update in helm charts & dockerfile(s)

Cherry-picking & Releasing

(Tasks must be performed in the correct order!)

• Checkout Release branch (e.g. f-release)
• Update version number in pom.xml or container-tag.yaml in Release Branch
  • ... otherwise previous released version will be partly overwritten – and release will fail (see below)
  • ... only if version numbers were not updated in after the last release)
  • For example, Information Coordinator Service
    • (Java) Pom: pom.xml
      
      • https://gerrit.o-ran-sc.org/r/c/nonrtric/plt/informationcoordinatorservice/+/8931/2/pom.xml
    • (Golang or Python - No POM file) container-tag.yaml
      • https://gerrit.o-ran-sc.org/r/c/sim/a1-interface/+/8933/2/near-rt-ric-simulator/container-tag.yamlFor example, A1 Simulator 
• Cherrypick changes as needed - either one at a time or as a squashed commit (see below)
  
  • Do in reverse order – oldest -> newest
  • .. then commit & review & merge the change to the branch
• Create Staging release
  • Last cherrypick above once complete should create, a new Staging image (& maven artifacts if maven releases are used) using version numbers in pom.xml or container-tag.yaml 
  • (If no cherry pick, or no update in 30 days last commit on branch should be re-merged – will create snapshot)
  • (Note, it seems GO projects do not need a staging image. But may need a recent snapshot build. Skip this step)
  • Some repos do NOT have a staging image automatically created.
    • See https://lf-o-ran-sc.atlassian.net/wiki/display/ORAN/O-RAN+Developer%27s+Guide+to+CI+Resources+and+Processes+at+the+LF#ORANDeveloper'sGuidetoCIResourcesandProcessesattheLF-TriggeringJenkinsjobsfromGerrit 
    • To manually trigger staging use comment “stage-release” on the relevant gerrit review to create a staging image. (Note this job also strips “–SNAPSHOT” from the image name if –SNAPSHOT is used)
  • Useful link to view if tagged staging image is created/correct: https://nexus3.o-ran-sc.org/#browse/browse:docker.staging:v2%2Fo-ran-sc
• Release Staged Image (from Release branch)
  • Find commit ID for last commit (e.g. git log –all)
  • Edit & commit container file in /.releases folder
    • See https://lf-o-ran-sc.atlassian.net/wiki/display/ORAN/O-RAN+Developer%27s+Guide+to+CI+Resources+and+Processes+at+the+LF#ORANDeveloper'sGuidetoCIResourcesandProcessesattheLF-ReleasingaDockerartifact
    • For Example: A1 Policy Management Service: https://gerrit.o-ran-sc.org/r/c/nonrtric/plt/a1policymanagementservice/+/8953
    • ... make sure to update BOTH of the version numbers to the latest version
    • ... similar process in ONAP https://wiki.onap.org/pages/viewpage.action?pageId=68545910
    • Documentation of this step: https://github.com/lfit/releng-global-jjb/blob/master/docs/jjb/lf-release-jobs.rst  && https://lf-o-ran-sc.atlassian.net/wiki/display/ORAN/O-RAN+Developer%27s+Guide+to+CI+Resources+and+Processes+at+the+LF#ORANDeveloper'sGuidetoCIResourcesandProcessesattheLF-ReleasingaDockerartifact
  • Review will not pass ‘verify’ step if the referenced snapshot/staging image cannot be found
  • Merge the commit, which will trigger the release operation
    • On merge, image will appear in ‘releases’ docker repo,
    • This job literally copies the referenced version from the source image store/repo (docker-staging) into the target image store/repo (docker-releases)
    • This job also performs git tag (<version number>) added to the referenced commit above.
  • Note, this can only be done ONCE for each release version – re-runs of this operation will not upload a new image with the same version number. Messed-up release images cannot be removed. If you make a mistake at this stage you must start again with a new version number.
  • Useful link to view if tagged released image is correct: https://nexus3.o-ran-sc.org/#browse/browse:docker.release:v2%2Fo-ran-sc
• Release Staged Maven artifacts – if enabled
  
  • Find Jenkins staging job id for the commit to release (e.g. the last cherrypick above)
    • For example, for Information coordinator Service the appropriate job is  nonrtric-plt-informationcoordinatorservice-maven-stage-f-release defined in ci-management repo …
    • The job ID will be visible in the comments/log of the appropriate commit that generated the staged version (e.g. the last cherrypick above, or the commit with 'stage-release' triggering comment)
  • Edit & commit maven file in the in /.releases folder
    • For example e.g. for Information coordinator Service
      • https://gerrit.o-ran-sc.org/r/c/nonrtric/plt/informationcoordinatorservice/+/8944
    • Documentation of this step: https://github.com/lfit/releng-global-jjb/blob/master/docs/jjb/lf-release-jobs.rst && https://lf-o-ran-sc.atlassian.net/wiki/display/ORAN/O-RAN+Developer%27s+Guide+to+CI+Resources+and+Processes+at+the+LF#ORANDeveloper'sGuidetoCIResourcesandProcessesattheLF-ReleasingaJava/mavenartifact
  • On merge, maven artifact will appear in ‘releases’ maven repo
  • Useful site to browse the maven repo to check maven artifact version is present: https://nexus.o-ran-sc.org/content/repositories/releases/org/o-ran-sc/
• Update Release Notes in Release Branch AND master branch – add commit ID of the release commit
  • For example, for Information coordinator Service:
    • f release branch /docs/release-notes.rst
      • https://gerrit.o-ran-sc.org/r/c/nonrtric/plt/informationcoordinatorservice/+/8948
    • master branch /docs/release-notes.rst
      
      • https://gerrit.o-ran-sc.org/r/c/nonrtric/plt/informationcoordinatorservice/+/8947
• Uptick version number AGAIN in pom.xml or container-tag.yaml in Release Branch (See step 2 above)
  
  • For example, Information Coordinator Service
    • (Java) Pom: pom.xml
      
      • https://gerrit.o-ran-sc.org/r/c/nonrtric/plt/informationcoordinatorservice/+/8958
  • For example, A1 Simulator 
    • (Golang or Python - No POM file) container-tag.yaml
      • https://gerrit.o-ran-sc.org/r/c/sim/a1-interface/+/8957/1/near-rt-ric-simulator/container-tag.yaml
• Now find & fix all documentation, tests, script file, helm charts etc referring to the old version number! :-O

How to Cherry Pick lots of commits as a single Squashed Commit

• Checkout Release branch  (e.g. f-release)
• $ git review –l
  • List reviews if exists
• $ git review -d <change_id>
  • Download the review if exists)
• $ git cherry-pick <commit_hash_3> <commit_hash_2> <commit_hash_1> ….
  • Cherry pick desired commits in order from oldest to youngest
• $ git status
  • Check branch status to see how many commits your branch is ahead
• $ git rebase -i HEAD~<diff_commit_count_number> (diff_commit_count_number: the number of commits cherrypicked in prev. step)
  • When the git edit window is opened, leave the pick on the first and replace 'pick' with 's' on the remaining commits.
    • :wq (to save/exit squashing (if using vi as git edit))
  • When the git edit window is opened for second time to edit commit messages, edit them all as you needed
    • :wq (to save/exit commit message editing (if using vi as git edit))
• $ git status
  • Now you see that only one commit ahead
• $ git commit –amend
  • You may change your commit message as you needed e.g. Patch set 2: Squash commits and cherry pick
• $ git review --verbose --dry-run branchname
  • dry-run review operation before apply, Do not forget the branchname! e.g. f-release, be careful when pointing <parent_branch_info>
• $ git review --verbose branchname
  • send your review that includes the squashed commit as a new patch set on the same change_id checked-out at ‘git review –d’ step above