Page History

...

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:
   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 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:

...

---
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
      version: 1.0.0-20190806T184921Z
    - name: test-frontend
      version: 1.0.0-20190806T184921Z

1. 1. Go to Jenkins and select the tab for the product to release.
   2. Find the link for the "<product>-maven-stage-master" job and click it.
   3. From the list of jobs, find the number for the job that created the artifact to release, the date of the run can be of help here.
   4. Put the number at the end of the "log_dir" value seen in the example below.
2. Alternative way to find Jenkins stage job.
   
   1. Look among its output logs for the file with the name: staging-repo.txt.gz, it will have a URL like this:
   2. https://logs.acumos.org/production/vex-yul-acumos-jenkins-1/common-dataservice-maven-dl-stage-master/4/staging-repo.txt.gz
3. Create a new/update existing 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.
4. Create a new change set with just the new file, commit to git locally and submit the change set to Gerrit.
5. 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.

After the release merge job runs to completion, the container images should appear in the Nexus3 release registry.

Releasing a Python package

For a Python package the release yaml file must list the log directory, python version and more. Example release yaml file content:

---
distribution_type: pypimaven
version: 1.0.0
project: example-project
log_dir: ricexample-pltproject-libmaven-rmr-python-pypi-merge-master/1
pypi_project: rmr
python_version: '3.7'
version: 1.0.0
project: myproject

If you use a valid decimal value anywhere (like 3.7 above), put it in single quotes so it can be parsed as a string, not a number.

After the release merge job runs to completion, the packages should appear in the https://pypi.org index.

Releasing a PackageCloud DEB/RPM package

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
      version: 1.0.0-20190806T184921Z
    - name: test-frontend
      version: 1.0.0-20190806T184921Z

After the release merge job runs to completion, the container images should appear in the Nexus3 release registry.

Releasing a Python package

For a Python package the release yaml file must list the log 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

If you use a valid decimal value anywhere (like 3.7 above), put it in single quotes so it can be parsed as a string, not a number.

After the release merge job runs to completion, the packages should appear in the https://pypi.org index.

Releasing a PackageCloud DEB/RPM package

2020-Dec-14: There is a process that involves the keyword "stage-release" (see section "Triggering Jenkins jobs from Gerrit" above) to publish packages to packagecloud. This works with two merges. First one with updates to ci/package-tag.yaml and ci/control. Merge that change and after merging add a comment with only the keyword "stage-release". After this create a second review for an updated "releases/*.yaml" with correct version, log_dir and ref with commit hash. Submit that change for merging as well. This will do the actual moving of the package from the staging directory in packagecloud to the release directory. A bit of information on this is also available in section "PackageCloud Release Files" from this LF guide: link.

OLD notes: The self-release process for PackageCloud is in active development as of December 2019. Until it is ready, write a ticket at https://jira.linuxfoundation.org/servicedesk

...

After creating or modifying a YAML file, submit the change to Gerrit where it will be verified and can be reviewed. Only the LF Release Engineering team can merge changes to the ci-management repository.

When creating new types of jobs follow these steps (see IT-25277 support case):

1. Adding a jobs yaml file
2. Making sure `mvn-settings` is set.
3. Creating a support request to create jenkins credentials (As pointed by `mvn-settings`)
4. Adding the set of settings files that point to jenkins credentials. 

Choosing a build node

Every project has a set of predefined OpenStack virtual machine images that are available for use as build nodes.  Choosing a build node determines the software image, number of CPU cores and amount of physical memory.  Build node names, for example "centos7-builder-1c-1g", are maintained in the ci-management repository as files in this directory:

...

After pushing a job to the sandbox, either via the Jenkins `deploy`jjb-jjb` deploy` job or directly, you can run the job on the code in your repository, usually the master branch, to test the job. Follow this procedure:

...