# git clone the repo, cd to the repo directory, then: COMMITID=$(git log -1 |head -1 |cut -f2 -d' ') echo $COMMITID |
At the time of releasing, binary artifacts built from O-RAN SC source code such as docker container images are "released" to public repositories (e.g. docker.io) with Linux Foundation signature. Depending on the type of a binary artifact, it may be released by a self-service process or a manual process.
The self-service process applies to docker images, Maven artifacts, and Pypi packages. The contributor making the request will need to edit an artifact specification file describing which artifact to release. Then a predefined Jenkins Job will be triggered to complete the releasing process.
Detailed documentation can be found at: https://docs.releng.linuxfoundation.org/projects/global-jjb/en/latest/jjb/lf-release-jobs.html
For artifact of a different type, the releasing is done manually via a Linux Foundation helpdesk ticket.
.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.
The first job (release-verify job) is to be triggered when an artifact release yaml file for the repo is submitted into Gerrit for review, similar to how regular verify jobs being triggered when code change submission happens. The release-verify job verifies all parameters specified in the artifact release yaml file are valid and the artifact to be released actually exits in the snapshot/staging repository.
The second job (release-merge job) is to be triggered when an artifact release yaml file for the repo is accepted by a repo committer and merged, similar to how regular merge jobs being triggered when code change submission being merged. The release-merge job would complete the pulling of the artifact from its source repo (snapshot or staging) then pushing onto its target (release) repo.
Because releasing an artifact generally involves fetching the artifact from its source repo (a snapshot or staging repo) and then publishing it onto a release repo, the artifact must already exist on the source repo. For example if a docker image is to be released, such an image must exist on O-RAN SC's staging Nexus3 repo.
Here are the steps for check for the existence of a docker image:
If the to be released image (or tag) is not there, there can be several reasons:
For the first two cases, we need to regenerate the image. This can usually be done in one of two ways.
If it is the 3rd case, then we need to investigate why the image has never been generated by finding the merge job that would generate the image and look into its logs.
When the preparation for releasing an artifact is complete, we have the release jobs and the artifact exists, it is time to edit the release file. This is the file placed under the release or .releases directory repo root that describes the artifact to be released. For example, below is the release file for o-ran-sc/it-dep-secret container:
--- distribution_type: container container_release_tag: 0.0.2 container_pull_registry: nexus3.o-ran-sc.org:10004 container_push_registry: nexus3.o-ran-sc.org:10002 project: it/dep ref: b1cc45af5be31e34bd4cc04554a064ed0143b711 containers: - name: it-dep-secret version: 0.0.2 |
Note that values on lines 3, 6, 7, 9, and 10 need to be adapted for the repo and container to be released.
Line 3: the tag to be used for release container;
Line 6: which repo;
Line 7: the $COMMITID that we identified earlier;
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).
Detailed documentation can be found at: https://docs.releng.linuxfoundation.org/projects/global-jjb/en/latest/jjb/lf-release-jobs.html. In particular, finding the section about "Release Files" for the type of artifact of interest.
Although it is okay to keep multiple of such release yaml files under releases or .releases, each commit of changes under this directory can ONLY CHANGE ONE FILE.
To be added
To be added
For types of artifact that are not listed in the self-service releasing process, they can be released by making request to Linux Foundation Helpdesk by filing a ticket at: https://jira.linuxfoundation.org/servicedesk/customer/portal/2/create/107.