...
- 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"
- Once a release candidate is build using gerrit-maven-stage, a new file will be posted must be added to your project repo describing the release .and referring to the gerrit-maven-stage log:
- This file needs to be located in the root repo under a "releases" folder.
- An example can be viewed here: https://github.com/lfit/releng-global-jjb/blob/master/docs/jjb/lf-release-jobs.rst
- Name of the file should match the semantic version of the release being published. (For example: releases/1.0.0.yaml)
- distribution_type: 'maven' (Future expansion will allow "container" to be provided"
- version: '#.#.#' (Release semantic version)
- project: 'project-name' (Project name, for example 'ccsdk-parent')
- log-dir: 'pointer_to_maven_stage_job/build_number/' (for example: 'ccsdk-parent-maven-stage-master/2/')
- maven_central_url: 'oss.sonatype.org' ( Optional, in case the team want's to publish to Maven Central)
- This file will trigger "{project-name}-release-verify-{stream}"
- This job can also be triggered using the comment "recheck|reverify"
- The verify job will make sure the release file contains the needed information and that the candidate exists.
- Tech team needs to +2 this new change and merge it. Please do not override any -1 Verify from Jenkins.
- The merge will trigger "{project-name}-release-merge-{stream}"
- This job can also be triggered using the comment "remerge"
- This job will push the release and tag the repo.
...