Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Current »

LF is working on optimizing the release process overall.

Our goal is to help PTLs and teams handle their releases as much as possible with little to no LF intervention.


Ongoing work for Nexus 2 Maven releases

For Nexus2 Maven releases, LF team is working on migrating the teams to use global-jjb {project-name}-maven-stage-{stream} 

This job performs the following:

  1. Removes "-SNAPSHOT" from all pom files so that the push can be done in staging
  2. Produces a taglist.log, project.patch, and project.bundle files
  3. Runs a mvn clean deploy to a local staging repo
  4. Pushes the staging repo to a Nexus staging repo https://nexus.onap.org/content/repositories/<REPO_ID> (REPO_ID is saved to staging-repo.txt on the log server)
  5. Archives taglist.log, project.patch, and project.bundle files to log server

Currently, having teams using {project-name}-maven-stage-{stream}  will already reduce the time LF takes to make a release to just the time it takes to make 1 click in Nexus2.

LF team is also working on automating that last step. 


Ongoing work for Nexus 3 Docker releases

Currently, there is no job in global-jjb that helps on this. 

Internally, we had some blockers while trying to add the signatures, but now that this is possible in Maven artifacts, we can start working on incorporating the same into Docker releases. 


Migration to DockerHub

There are few things to consider for this migration. Currently they are not well planned on regards on how should they be addressed but this is hopefully getting clearer as we go

  • Tech teams make Nexus3 registry references in the code (pom.xml, Docker files...) We need to know how are the teams going to change these references to Dockerhub without disrupting much of their current procedures
  • LF has to update the docker templates we have to publish to Dockerhub. We need to make sure we wither create a new template or make this information into a parameter we can slowly modify as we transition 
  • Currently DockerHub has all releases up to date, is the team going to need any snapshots? 

Proposed migration plan and stakeholders

Activities happening or that can happen right now:

  • Docker templates:
    • RELENG: Templates for Maven-Docker projects → COMPLETED
    • RELENG: Templates for Docker only projects → COMPLETED
    • ONAP: Define component dependency chart → PENDING (1 hr, maybe a PTL meeting task June 17?) By examining jenkins jobs logs We could make preliminary list here https://paste.ubuntu.com/p/QwYKgSmg7P/


Order of activities that will happen after TSC approval and after Nexus2 migration (starting July 22):

  1. RELENG + ONAP + MULTIARCH: Schedule a call to plan the migration → 1 hr
  2. ONAP + MULTIARCH: Modify any docker registries mentions in the code and any changes to the code to make it multi-ach friendly. → (2 hr mini avarage, Time depends on # of components per project)
  3. ONAP + RELENG: Add global-jjb jobs in project yaml files. → 20 mins
  4. ONAP + RELENG + MULTIARCH: Test jobs and address any issues → Best case scenario 2 hr
    1. Verify that the right artifacts were produced and pushed into DockerHub -> 1 hr
    2. Attempt to run multi-architecture pulls and make sure DockerHub calls the right manifest -> 1 hr
    3. Functional tests? Scope and ETA need to be defined by tech team.
  5. ONAP: Confirm dependencies and needed images appear in Docker Hub. → 20 min
  6. ONAP + RELENG: Remove deprecated Nexus3 jobs → 20 min


Notice these are best case scenario situations. If any ONAP component requires an upgrade on the global-jjb jobs, such upgrade will need to be evaluated and developed by RELENG.

At all times (until #6 is executed), Nexus3 jobs could be running in parallel as long as the Nexus3 registries are still used.

  • No labels