Page History

...

.To check whether self-service release jobs have already been defined for a specific repo, go to http://jenkins.o-ran-sc.org and among the Jenkins jobs listed under the tab for the repo look for two jobs named {{ repo-name }}-release-verify and {{ repo-name }}-release-merge.  For example it-dep-release-verify and it-dep-release-merge for the it/dep repo.

...

1. If there is no newer changes merged into this repo after the code submission that triggered the building of the to-be-release docker container image, we need to use the Gerrit UI to find this already merged code change, and click on the "reply" button.  In the message box, type the magic word "remerge".  This key word will trigger the merge job and the merge job will rebuild the docker image.
   1. One way to locate the last Gerrit submission that triggered the merge build is to go to jenkins.o-ran-sc.org, locate the merge job that built the docker image among the list of Jenkins jobs for this repo on the repo tab, click on the job to bring out its build history on the left side of the page, then find the last bulid build of this job from the left panel.  The build's information detail (by clicking on the build number) contains a link to the Gerrit submission that triggered the build.  This is the Gerrit change that we want to reply to with the magic word to.
   2. If the docker container image of interest is one of several images built from this repo, make sure looking for the code change that triggered the building of this specific docker container image.  This needs to be done very carefully because some change may trigger multiple docker container image builds, and different changes may cover different sets of container image builds.  One rather conservation way to remerge of remerging in this kind of repos is to not only "remerge" the last change that triggered the image build for the container of interest, but also "remerge" all changes after this change in the order that such changes are submitted to originally merged into Gerrit.
2. If there are newer code changes merged after the change that triggered the building of the to-be-release docker container image, "remerge" such an out-of-order change may cause unexpected results.  In this case an alternative method can be used instead.  That is, to make a "no-op" code change to a file that will trigger the rebuilding of the to-be-release docker container image.  For example, adding or removing some comment text to the Dockerfile for the container.

...

Line 9: name of the to-be-released docker image on its source repo (pull registry)  (no need to have the o-ran-sc/ prefix here);

Line 10: version tag of the to-be-released docker image on its source repo (pull registry).

...