Page History

...

Post "run-sonar" to run the Sonar analysis job (if applicable).

Releasing

...

Binary Artifacts

In the LF environment, "to release" means to promote an artifact from a staging area that is ephemeral a release area that is permanent. For example, move a Docker image from a Nexus staging registry where images are deleted after two weeks to a Nexus release registry where images are kept "forever." This process is implemented by Jenkins jobs that react to files committed via Gerrit. Guarding the process with the Gerrit merge task means only committers can release artifacts.

Once testing against the staging repo version has been completed (see above ) and the project has determined that the artifact in the staged repository is ready for release, the project team can use the new-for-2019 self-release process. Additional documentation is here: https://docs.releng.linuxfoundation.org/projects/global-jjb/en/latest/jjb/lf-release-jobs.html

Releasing a Java/maven artifact

1. Find the Jenkins stage job that created the release candidate.  Look among its output logs for the file with the name:

Once testing against the staging repo version has been completed (see above ) and the project has determined that the library in the staged repository is ready for release, the project team can use the new-for-2019 self-release process as follows.

Please note this requires dedicated jobs in the Jenkins server, created via appropriate entries in the JJB templates. Also see documentation at https://docs.releng.linuxfoundation.org/projects/global-jjb/en/latest/jjb/lf-release-jobs.html

Directions:

1. Find the Jenkins stage job that created the release candidate.  Look among its output logs for the file with the name: staging-repo.txt.gz, it will have a URL like this:https://logs.acumos.org/production/vex-yul-acumos-jenkins-1/common-dataservice-maven-dl-stage-master/4/ staging-repo.txt.gz, it will have a URL like this:
   1. https://logs.acumos.org/production/vex-yul-acumos-jenkins-1/common-dataservice-maven-dl-stage-master/4/staging-repo.txt.gz
2. Create a new Create a new release yaml file in the directory "releases/" at the repo root.
   
   1. The file name should be anything, but most projects use a pattern like "release-maven.yaml". An example of the content appears below.
   2. The file content has the project name, the version to release, and the log directory you found above, altho in abbreviated form.
3. Create a new change set with just the new file, commit to git locally and submit the change set to Gerrit.
4. After the verify job succeeds, a project committer should merge the change set. This will tag the repository with the version string AND release the artifact.

Example release yaml file content:

1. . This will tag the repository with the version string AND release the artifact.

Example release yaml file content:

---
distribution_type: maven
version: 1.0.0
project: example-project
log_dir: example-project-maven-stage-master/17/

After the release merge job runs to completion, the jar files should appear in the Nexus2 release repository.

Releasing a Docker artifact

For a Docker image the release yaml file must list the desired release tag and the existing container tags. Example release yaml file content:

distribution_type: container
container_release_tag: 1.0.0
container_pull_registry: nexus.o-ran-sc.org:10003
container_push_registry: nexus.o-ran-sc.org:10002
project: test
ref: b95b07641ead78b5082484aa8a82c900f79c9706
containers:
    - name: test-backend
      ---
distribution_type: maven
version: 1.0.0
project-20190806T184921Z
    - name: example-project
log_dir: example-project-maven-stage-master/17/test-frontend
      version: 1.0.0-20190806T184921Z

After the release After the merge job runs to completion, the jar files container images should appear in the Nexus2 Nexus3 release repositoryregistry.

Releasing

...

a Python package

For a Python package This is very similar to the process for releasing a Java/maven artifact as describe above. However the content of the release yaml file is different. The file must list the desired release tag and the existing container tagslog directory, python version and more. Example release yaml file content:

-

-

-
distribution_type: pypi
log_dir: ric-plt-lib-rmr-python-pypi-merge-master/1
pypi_project: rmr
python_version: 3.7
version: 1.0.0

project: myproject

After the release merge job runs to completion, the container images packages should appear in the Nexus3 release registryhttps://pypi.org index.

Jenkins Job Builder Templates

...