Process works, feel free to use it.
FIRST SUCCESSFUL RELEASE EXAMPLE CAN BE VIEWED HERE:
https://gerrit.onap.org/r/#/c/clamp/+/95770/1/releases/4.1.2-container.yaml
Self releases are now possible after the migration to latest global-jjbs staging jobs
...
- The tech team needs to make sure their committer list is up to date as these will be the people approved to make releases.
- The reason behind this, only committers can +2 and merge changes in their tech team repo.
- The releases merge job will be triggered by files merged in the repo and will execute a release.
- Tech team needs to add "{project-name}-gerrit-release-jobs" to their ci-management yaml files.
- This group introduces "gerrit-release-verify" and "gerrit-release-merge"
- Teams that have added these jobs for Nexus2 releases, will need to use a docker node if they want to use docker self releases. For example: https://gerrit.onap.org/r/#/c/ci-management/+/95775/
- Once a release candidate is build using gerrit-maven-docker-stage, a new file must be added to your project repo describing the release and referring to the gerrit-maven-docker-stage log:
- Please create 1 releases file per Gerrit repo. The job will throw an error if found more than 1 release files: https://github.com/lfit/releng-global-jjb/blob/master/shell/release-job.sh#L49
- This file needs to be located in the root repo under a "releases" folder.
- An example can be viewed here: https://gerrit.onap.org/r/#/c/clamp/+/95770/
- Name of the file should match the semantic version of the release being published. (For example: releases/1.0.0-container.yaml) This is not enforced, but is good to follow a convention across repos.
- In reality, the file can be named whatever but we want to keep consistency and recommend teams to use #.#.#-container.yaml (Docker) and #.#.#.yaml (Maven)
- distribution_type: 'container'
- container_release_tag: '#.#.#' (Release semantic version, release version that will appear in the docker.releases repo)
- tag_release: false (By default, tagging a repo with the container_release_tag is set to true. If you want to skip it, set it to false)
- project: 'project-name' (Project name, for example 'ccsdk-parent')
- log-dir: 'pointer_to_docker_stage_job/build_number/' (for example: 'ccsdk-parent-maven-docker-stage-master/2/')
- ref: 'commit that the team would like to tag' (If the repo was already tagged when maven releases was processed, no re-tagging will happen. This job just tags using the version number that is being released, it does not tag official ONAP releases like 5.0.0-ONAP)
- containers: list of image names and tags to be pulled for the releases. For example:
- Name of the file should match the semantic version of the release being published. (For example: releases/1.0.0-container.yaml) This is not enforced, but is good to follow a convention across repos.
...