Page History

...

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

Releasing your

...

Java/maven artifact

Once testing against the staging repo version has been completed (see above ) and the project has determined that the library in the staged When the project determines that an artifact in a staging repository is ready for release, a release can then be performed as followsthe 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 of the staging repository: staging-repo.txt.gz, it will have a URL like this:
   1. https://logs.o-ran-scacumos.org/production/vex-yul-oacumos-ran-sc-jenkins-1/common-dataservice-maven-dl-stage-master/4/staging-repo.txt.gz
2. Open a ticket with the LF helpdesk to sign the artifact(s) in the staging repo and promote them to the release repo. Example request is below.
   
   1. Send email to helpdesk@o-ran-sc.org with CC to affected people, only To and Cc people can see the ticket status
   2. Supply the Jenkins job URL and Jenkins log URL from above.
   3. Supply the name of the autorelease repository.
3. Add a tag for the release on the Gerrit web site.

Example release request:

Please release the PROJECT-NAME jar and docker image at version VERSION
Stage job:
    https://jenkins.o-ran-sc.org/job/PROJECT-stage-master/201/
Logs:
    https://logs.o-ran-sc.org/production/vex-yul-o-ran-sc-ra-jenkins-1/PROJECT-stage-master/201/
Autorelease repo name:
    autorelease-1150
Thanks in advance

1. 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.
2. Create a new change set with just the new file, commit to git locally and submit the change set to Gerrit.
3. 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:

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

Releasing your Docker artifact

This is nearly identical to the process for releasing a Java/maven artifact as describe above. Only the content of the release yaml file is slightly different. Example release yaml file content:

After the merge job runs to completion, the artifacts should appear in the Once complete the artifact(s) will appear in the Nexus2 release repository and/or Nexus3 release registry.

Jenkins Job Builder Templates

...