Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

URLDescription
https://identity.linuxfoundation.orgThe Linux Foundation identity management web site.
https://gerrit.o-ran-sc.orgThe Gerrit code review server hosts the Git repositories and supports the review and merge workflow. The review process basically requires all users to follow something like a git pull-request process, but restricts the publication (push) of private branches.
https://jenkins.o-ran-sc.orgJenkins is the continuous-integration server aka the build server. All users can see the contents of the Jenkins; no users can directly modify the configuration nor start a job in this Jenkins. Jobs are configured by Jenkins Job Builder (JJB) files in the ci-management gerrit repository.
https://jenkins.o-ran-sc.org/sandboxThe Jenkins sandbox is a place for testing Jenkins job configurations.  After requesting Users must request login credentials on the sandbox, it does not use the LF identity or single sign-on feature.  After receiving access, users can create jobs, reconfigure jobs, trigger builds etc. New JJB templates should be tested in the sandbox before submitting for review and use on the main Jenkins server.
https://jira.o-ran-sc.orgJira is the web site that supports agile development with epics, user stories, and especially issues (bug reports).
https://nexus.o-ran-sc.org

Not heavily used by this project because Java is not a key technology, this Nexus 2 repository holds Maven (jar and pom) artifacts produced by builds. Snapshot and staging builds are all deployed to this repository.  Release artifacts are created by promoting artifacts manually from the staging repository after suitable approval. Publicly accessible to users without credentials. All users should be able to access and browse artifacts through this URL.

https://nexus3.o-ran-sc.org/

This Nexus 3 server stores project Docker images and also mirrors external registries. Supports the following:

  • Public mirror registry: nexus3.o-ran-sc.org:10001. This acts as a mirror of the public registry at docker.io.
  • Release registry: nexus3.o-ran-sc.org:10002. This is a VIEW offering access to the public registry mirror AND the project releases (docker images in the release registry). Projects may request promotion of their docker images to this registry by using the self-release process.
  • Snapshot registry: nexus3.o-ran-sc.org:10003. Not used in ORAN, but in other projects, the snapshot registry contains docker images produced by certain Jenkins jobs.
  • Staging registry: nexus3.o-ran-sc.org:10004. This contains release candidate docker images produced by merge jobs.

These registries are open for anonymous read access.  The Jenkins server has credentials to push images to the snapshot and staging registries, and to promote images to the release registry. Manual push of images is not supported.

https://packagecloud.io

This site hosts binary artifacts such as Debian (.deb) packages, Red Hat Package Manager (.rpm) packages and more in these repositories:

  • o-ran-sc/master
  • o-ran-sc/staging
  • o-ran-sc/release

Also see Binary Repositories at PackageCloud.io

https://sonarcloud.ioSonar tools analyze Java and Python code for quality issues and code coverage achieved by unit tests (JUnit, tox) and publish results to this cloud-based server.

...

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

Jenkins Job Builder Templates

All jobs in the Jenkins server are generated from Jenkins Job Builder (JJB) templates. The templates are maintained in the "ci-management" git repository.  A project template is defined for each project in a YAML file (e.g., "com-log.yaml").  The project templates use job templates defined by the Linux Foundation Global JJB as well as job templates custom to this project.

Setting up development environment

Making Java code checked by Sonar

To make Java code checked by Sonar an addition to the projects pom file is needed, see below.

Setting up development environment

Making Java code checked by Sonar

To make Java code checked by Sonar an addition to the projects pom file is needed, see below.

<plugin>
    <groupId>org.sonarsource.scanner.maven</groupId>
    <artifactId>sonar-maven-plugin</artifactId>
    <version>${sonar-maven-plugin.version}</version>
</plugin>
<plugin>
    <groupId>org.jacoco</groupId>
    <artifactId>jacoco<plugin>
    <groupId>org.sonarsource.scanner.maven</groupId>
    <artifactId>sonar-maven-plugin</artifactId>
    <version>${sonar-maven-plugin.version}<<version>0.8.4</version>
</plugin>
<plugin>    <executions>
    <groupId>org.jacoco</groupId>    <execution>
    <artifactId>jacoco-maven-plugin</artifactId>
    <version>0.8.4</version>
    <executions>
       <execution>
          <id>default-prepare-agent</id>
          <goals>
             <goal>prepare-agent</goal>
          </goals>
       </execution>
       <execution>
          <id>default-report</id>
          <phase>prepare-package</phase>
          <goals>
             <goal>report</goal>
          </goals>
       </execution>
    </executions>
</plugin>

...

  1. In Eclipse, right click on the project and select "SonarLint → Bind to SonarQube or SonarCloud...".
  2. In the dialog, press the "New" button.
  3. Make sure the "sonarcloud" radio button is selected and press "Next".
  4. If you do not have a token generated in SonarCloud, press the "Generate token" button. Otherwise you can reuse yor token.
  5. Follow the instructions in the web page you are redirected to to generate the token.
  6. Paste the token in to the "Token:" box and press "Next".
  7. In the "Organization:" box, type "o-ran-sc" and press "Next".
  8. Press "Next".
  9. Press "Finish".
  10. Select "Window → Show View → Other..." and then "SonarLint bindings".
  11. In the view, doubleclick the new binding.
  12. In the dialog, Press "Add", select the project to bind, press "Ok", and press "Next".
  13. Type your project's name. When it show up in the result list, select it and press "Finish".

Now Sonar issues should show up in your code.

Note! At the moment there is a bug that show up in your code.Note! At the moment there is a bug that show up if Lombok is used in the code. To see when a fix is released, follow this link Lombok issue.if Lombok is used in the code. To see when a fix is released, follow this link Lombok issue.

Jenkins Job Configuration

All jobs in the Jenkins server are generated from Jenkins Job Builder (JJB) templates. The templates are maintained in this project's "ci-management" git repository. The templates use features from the Linux Foundation Global JJB as well as features custom to this project.

Some documentation resources:

Jenkins Job Builder: https://docs.openstack.org/infra/jenkins-job-builder/

LF Global JJB: https://docs.releng.linuxfoundation.org/projects/global-jjb/en/latest/

LF Ansible: https://docs.releng.linuxfoundation.org/en/latest/ansible.html

Writing JJB Templates

A project template is defined for each repository. The convention is to create a directory to group the CI material for each repository, and in that directory create at least one YAML file. For example, "ci-management/jjb/com-log/com-log.yaml". Every repository should have at least the following items defined in its yaml file:

  • Project view.  This causes a tab to appear on the Jenkins server that groups all jobs for the repository together.
  • Info file verifier.   This checks changes to the repository's INFO.yaml file.
  • Verify and merge jobs appropriate for the implementation language of the code in that repository.

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

Choosing a build node

Every project has a set of predefined OpenStack virtual machine images that are available for use as build nodes.  Each node has a different set of software. Discovering the exact software contents of a build node generally requires analyzing the ansible roles and packer commands that are also maintained in the ci-management repository. There are no easy short cuts here.

Testing JJB Templates

Job templates should be tested by creating jobs in the Jenkins sandbox, then executing the jobs against a branch of the repository, the master branch or any change set (review) branch can be used.  Jobs can be created in one of two ways:

  • Create jobs directly at the Sandbox from a personal computer. (This allows rapid edit/test cycles.)
    • Install the Python package jenkins-job-builder (version 3.2.0 as of this writing)
    • Create a configuration file with credentials
    • Test the templates locally: jenkins-jobs test -r jjb > /dev/null
    • Create jobs: jenkins-jobs --conf jenkins.ini update -r jjb YOUR_JOB_NAME > /dev/null
  • Post a special comment in the change set for ci-management and the primary Jenkins server will create new jobs in the sandbox. (Be patient if you choose this route.)
    • jjb-deploy YOUR_JOB_NAME*