Policy R8 Honolulu Independent Versioning And Release Process Plan

Consumed API from other projects

Project

API Dependency

Notes

Project

API Dependency

Notes

AAF

v2.1.21



Dmaap

v1.1.11



SDC

1.6.5 - sdc-tosca

1.4.1 - sdc-distribution-client



AAI

aai-schema 1.7.2



SO



REST - No direct link to any libraries

VFC



REST - No direct link to any libraries

SDNR



Dmaap - No direct link to any libraries

SDNC



REST - No direct link to any libraries

CDS

0.4.4

TODO


Published API - These projects use the policy libraries to build their code

Project

API

Notes

Project

API

Notes

OOF

Legacy Policy API

implemented in own python code

SDNC

Legacy Policy API

implemented in own code

DCAE

Policy Lifecycle API

Implemented own python code



1. Follow the process as outlined here: Independent Versioning and Release Process. Policy repositories inherit from oparent so release jobs will fail if any SNAPSHOT artifact is referenced in the pom.xml's.

  • Verify there are no SNAPSHOTs and we are up-to-date with other team's released artifacts. The CI/CD daily release job does this by automatically failing if a SNAPSHOT is defined in the pom.xml's.

  • Use the Self Releases Workflow (Nexus2) to release artifacts.   Look at comments by @Jorge Hernandez  for steps.

  • Update the OOM team K8S Helm Charts.

Note: If using maven version or release plugin, also manually check the versions are set correctly in the POMs, these plugins can miss POMs especially if they do not have Java source code in them.

            "mvn -DnewVersion=X.Y.Z-SNAPSHOT versions:set versions:update-child-modules versions:commit"



2. For any new changes to be done post-Release. Then the we must update to the next SNAPSHOT version:

Release Order

Repo (released version)

Notes

Example Commit(s) for upgrading versions

Release Order

Repo (released version)

Notes

Example Commit(s) for upgrading versions

1

policy/parent

3.3.0

all pom.xml's

version.properties

https://gerrit.onap.org/r/c/policy/parent/+/110016

2a

policy/docker

2.2.1

all pom.xml's

version.properties

In main pom.xml change the following properties

  • Ensure <parent> tag points to correct policy/parent version

Update Dockerfile in all repos with new version

https://gerrit.onap.org/r/c/policy/docker/+/114316

2b

policy/common

1.8.0

all pom.xml's

version.properties

In main pom.xml change the following properties

  • Ensure <parent> tag points to correct policy/parent version

https://gerrit.onap.org/r/c/policy/common/+/114285

3

policy/models

2.4.2

all pom.xml's

version.properties

In main pom.xml change the following properties

  • Ensure <parent> tag points to correct policy/parent version

  • policy.common.version



https://gerrit.onap.org/r/c/policy/models/+/114286

4a

policy/api

2.4.2

all pom.xml's

version.properties

In main pom.xml change the following properties

  • Ensure <parent> tag points to correct policy/parent version

  • policy.common.version

  • policy.models.version

In Dockerfile

  • Ensure base image version is correct

https://gerrit.onap.org/r/c/policy/api/+/119672

4b

policy/pap

2.4.2

all pom.xml's

version.properties

In main pom.xml change the following properties

  • Ensure <parent> tag points to correct policy/parent version

  • policy.common.version

  • policy.models.version

In Dockerfile

  • Ensure base image version is correct

https://gerrit.onap.org/r/c/policy/pap/+/114290

4c

policy/drools-pdp

1.8.2

all pom.xml's

version.properties

In main pom.xml consider changing the policy.common.version property:

  • Ensure <parent> tag points to correct policy/parent version

  • policy.common.version

  • policy.models.version

In Dockerfile

  • Ensure base image version is correct

Update policy/drools-applications dockerfile to pull this image (see below)

Update policy/drools-applications files:

  • pom.xml: version.policy.drools-pdp

https://gerrit.onap.org/r/c/policy/drools-pdp/+/114325

4d

policy/apex-pdp

2.5.2

all pom.xml's

version.properties

In main pom.xml consider changing the policy.common.version property:

  • Ensure <parent> tag points to correct policy/parent version

  • policy.common.version

  • policy.models.version

In Dockerfile

  • Ensure base image version is correct

https://gerrit.onap.org/r/c/policy/apex-pdp/+/114292

4e

policy/xacml-pdp

2.4.2

all pom.xml's

version.properties

In main pom.xml consider changing the policy.common.version property:

  • Ensure <parent> tag points to correct policy/parent version

  • policy.common.version

  • policy.models.version

In Dockerfile

  • Ensure base image version is correct

https://gerrit.onap.org/r/c/policy/xacml-pdp/+/114324

4f

policy/distribution

2.5.2

all pom.xml's

version.properties

In main pom.xml change the following properties

  • Ensure <parent> tag points to correct policy/parent version

  • policy.common.version

  • policy.models.version

In Dockerfile

  • Ensure base image version is correct

https://gerrit.onap.org/r/c/policy/distribution/+/114291

4g

policy/clamp

6.0.2

all pom.xml's

version.properties

In main pom.xml change the following properties

  • Ensure <parent> tag points to correct policy/parent version

  • policy.models.version

In Dockerfile

  • Ensure base image version is correct

https://gerrit.onap.org/r/c/policy/clamp/+/118101

5 - Dependent only on policy/drools-pdp

policy/drools-applications

1.8.2

all pom.xml's

version.properties

In main pom.xml change the following properties

  • Ensure <parent> tag points to correct policy/parent version

  • policy.common.version

  • policy.models.version

  • version.policy.drools-pdp



https://gerrit.onap.org/r/c/policy/drools-applications/+/114862



When branching, its easiest to update the .gitreview file ON the new branch in order to ensure that new gerrit submissions are tracked on that branch.

If this is not done, then one should specify the branch when submitting the git review. 'git review guilin'

[gerrit] host=gerrit.onap.org port=29418 project=policy/engine.git defaultbranch=guilin



When tagging for a release, the following commands can be used:

git tag -sm "8.0.0-ONAP Release" 8.0.0-ONAP <optional-commit-id> git push origin 8.0.0-ONAP

Most likely you will need 'gpg2' installed and configured for git in order to sign the tags. NOTE: ONAP is requiring that the tags be signed.

Release tags are best to be applied against the last commit that was for an image release. However, sometimes that does not apply if an image did not require a new release. So its possible some tags will be on the same commit across releases (eg policy/docker is one repo where that is true). Depending on when branching happens, some tags may not be visible in a log for a specific branch. Best to use the online gerrit gui to see all the tags for a repo.



Steps for Releasing and branching

Steps for Releasing and branching

Raise a review to refer released version of dependency (parent, common, models etc.)

Go to latest merged review of repo and comment “stage-release

It will trigger 2 Jenkins jobs - stage-master & docker-stage-master

NOTE: The "docker-stage-master" job will fail for drools-applications

Once the jobs are successful, create a yaml file for releasing maven artifacts first and raise a review.  This file can typically be generated using this script: mkart.sh

Once that is merged and build is successful, create another container.yaml file for releasing docker image and raise a review.  This file can typically be generated using this script: mkdock.sh

NOTE: Drools-applications will require a 2nd "stage-release" to be done due to the way it is built; the docker image requires the java artifacts to be released first, which are packaged into the image.

Once that is merged and build is successful, go to nexus3.onap.org & nexus.onap.org and verify that the image & artifacts were released 

Bump the snapshot version to next patch version and raise a review - Use this command “mvn versions:set -DnewVersion=<snapshot-version>

Update the patch version in "version.properties" file.

Below steps are ONLY needed when we are branching and proceeding to new release

Once that is merged and build is successful, go to gerrit and create a “honolulu” branch.

Once the branch is created, bump the master branch to next minor version using the same maven command, update the dependencies to the new SNAPSHOT versions, and raise a review

Finally go to honolulu branch and change the .gitreview file to point to honolulu as default branch and raise the review.