Skip to end of metadata
Go to start of metadata

This page explains the cycle of development, testing and release for Acumos platform components.  Please note that Java libraries (jar files) are stored in Nexus2 repositories, and Docker images are stored in Nexus3 registries.  Both have snapshot areas, staging areas and release areas.  A similar workflow is employed for both types of artifacts.

The recommended project release strategy - the progression from SNAPSHOT to release artifact - is as follows:

  1. The Jenkins server produces SNAPSHOT versions when fresh code is merged to Gerrit and stores them in the snapshot repository/registry.
  2. Developers deploy SNAPSHOT versions from a snapshot repository/registry to a development server and perform alpha testing.
  3. After success of alpha testing, developers create a release candidate by posting the comment "build release" on the latest & greatest Gerrit review that was merged.
    1. This job automatically strips all -SNAPSHOT suffixes from ALL versions of ALL artifacts listed in POM files!
    2. Developers must realize that this stage-for-release build will use only release versions of jar dependencies in their POM files - no SNAPSHOT versions.
    3. If the project produces a library (jar) file used by other components, the project lead should request promotion of THAT JAR ONLY from the staging repository to the release repository at this time, so that the library is available for other projects to use when building their release candidates.  See below for the steps to follow.
  4. Testers deploy release-candidate docker images from a staging registry to a testing server and perform system testing.
  5. After success of system testing, the project lead requests promotion of the docker image(s) from the staging registry to the release registry. This ensures the exact image that was tested is also provided for public use.  See below for the steps to follow.
  6. Developers bump the version number in their POM file(s) to prepare for the next version.

Requesting release at LF

To have an artifact promoted from a staging area to the corresponding release area, log into support.linuxfoundation.org and follow instruction from below PDF to request release and provide the Jenkins staging job URL.  Do this as early as possible, promotion may take 1-2 business days because it requires manual action by the LF release engineering team.

As of late 2019, projects can trigger self-promotion of maven and container artifacts.  Please see documentation at LF: https://docs.releng.linuxfoundation.org/projects/global-jjb/en/latest/jjb/lf-release-jobs.html


  • No labels

1 Comment

  1. Regarding point no. 5.  Till data project leads are never been informed about the testing status (at least I didn't get any email ).   This should be the Release Management team responsibility to release all the successfully tested module from staging to release repository instead of pushing to each project lead.