Table of Contents
...
Issue of dependency on Snapshot
Example of the problem:
Imagine you have your cpt A build working fine. Your build is depending on cpt B SNAPSHOT build.
For some good reasons, cpt B makes a new build. As cpt A relies on B SNAPSHOT (meaning latest build) when you rebuild cpt A if the build breaks you will not know if the problem is within cpt A or within its dependency cpt B.
To address the Snapshot dependency scenario, the idea is to move away from Snapshot dependency to "Release Artifact" dependency only. The word "Release Artifact" is loaded with the sense that the build is stable, has been thoroughly tested and can be used by another team. The "Released Artifact" is available within the "Nexus Release" repo (refer to Nexus section below for further description of Nexus repos). The PTLs and the project team decide on their own when to create a "Release Artifact". This approach allows to truly decouple the builds from each other and avoid the situation where something that was working fine before doesn't suddenly break due to snapshot changes.
...
One early idea was to embed the version manifest within the oparent artifact, perhaps as version properties within the POM file that can be directly consumed by downstream POMs. This approach, however, has some issues:
Just think about this scenario:
cpt A version 2.3.0 depends on o-parent 0.9.0
cpt A releases 2.3.1, which still depends on o-parent 0.9.0
Now, cpt A version in o-parent needs to be updated
Due to the change of the cpt A version in o-parent, o-parent itself needs to be bumped to 0.9.1. Now we have a circular dependency.
Each PTLs will need to update the manifest to declare the "Released" version available. In order to avoid the circular dependency issue, any updates to the version manifest, must NOT require any artifact to be version bumped and re-released.
...
ONAP is using 3 types of Nexus repos:
- Snapshot repo: used for merged artifactsartifacts from review branch and master that have not yet been verified by CSIT. After the committer has performed the code review (+2), has merged the code and the build is successful, the build artifact is within submits a patch for review, the artifacts are built and pushed to the Snapshot repo. It is expected to have multiple snapshots for a single repo per day. All snapshot artifacts have same version number. The artifact triggers CSIT testing is triggered after successful snapshot artifact build.
- Staging repo: used for snapshot artifacts built from master that have passed CSIT and are valid candidates for Release candidate. The Staging artifacts are used primarily by the Team for their own testing and for E2E Release testing. The Staging artifacts are not not meant for public consumption. Once a day, a new clean build is automatically performed (?). All Staging artifacts have same version number.
- Release repo: this is the place where the project Team (or Linux Foundation Releng Team) stores the artifacts that are deemed stabled for being consumed by the other project teams. Each team decides when to release. It is not expected to get a new release every day. No TSC approval is required for getting a new release artifact.
...