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.
Understanding the above, ONAP is maintaining a manifest of "Released Artifacts" outside the build process and outside of any binary artifacts. However, the manifest is still in source control. A specific version of this manifest will be blessed by TSC and used to make the "Named Release" (see definition of "Named Release" below).
Nexus
ONAP is using has 3 types of Nexus repos for artifacts:
- Snapshot repo: used for artifacts from review branch and master that have not yet been verified by CSIT. After the committer 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. CSIT testing is triggered after successful snapshot artifact buildthis should no longer be needed since there should no longer be cross-project SNAPSHOT dependencies and therefore there should be no reason to make SNAPSHOT artifacts available via Nexus.
- Staging repo: used for snapshot artifacts artifacts built from master and staged for further verification - those that have passed CSIT and are should be valid candidates for Release. The Staging artifacts are used primarily by the Team for their own testing and for E2E Release testing. The Staging artifacts are 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.
...