Self releases are now possible after the migration to latest global-jjbs staging jobs
gerrit-maven-stage and gerrit-maven-docker-stageCurrently Maven2 JAR artifacts self release process is finalized. Docker Images self releases
is still under construction.
Before teams start using self releases ...
...
- 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)
- tag_release: false (By default, tagging a repo with a release version 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_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.
After your self release ...
...
Once your self release file was merged and processed by "gerrit-release-verify" and "gerrit-release-merge"...
- Do not DO NOT attempt to revert files in releases/ → Even if the release was not needed, we need to keep track on what happened in that repo also the tag needs to be kept in the repo
- Do not DO NOT attempt to re-tag the repo with the same version → this will fail as the gerrit-release-merge job already tagged it
- Do not DO NOT modify releases files → Once a releases file is merged, it is immediately processed. If the team needs to release a new build number, please bump your versions and generate another stage-release
- Do not DO NOT re-use the same stage-release build number for multiple releases files → Once an autorelease package is pushed, it is closed and it cannot be re-released.
FEEDBACK:
Jonathan (AAF):
...
- LATE BREAKING: Call me dense, but I didn't realize that it is the CREATION and SUBMITTING of the releases/<version>.yaml that actually triggers the self-release. When you are going to a new version, i.e. "2.1.16", in my case, you need to REMOVE this file until you are actually ready to release. I put a "HowToRelease.txt" file explaining this in my home directory, because I'm sure I'll forget.
...
- MAKE SURE your project is 100% free from using nexus-staging-maven-plugin. This was a must do in the global-jjb migration and teams still using it WILL BE facing issues deploying all their artifacts.
- Using this plugin, pre-deploys image in a bad way before lftools has a chance to compile all artifacts needed for the release candidate
- DO NOT cherry-pick release files across branches. Duplicated release files will make the verify and merge job fail as those release were already processed.
- Releases from master should be created in master, releases from sub-branches like "el-alto" should be created in "el-alto"