Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Self releases are now possible after the migration to latest global-jjbs staging jobs

...

https://github.com/lfit/releng-global-jjb/blob/master/docs/jjb/lf-release-jobs.rst


How does it work?


The process is very simple. It will require for tech teams to post a new "releases" folder with a yaml file for each release

...

  1. The tech team needs to make sure their committer list is up to date as these will be the people approved to make releases.
    1. The reason behind this, only committers can +2 and merge changes in their tech team repo.
    2. The releases merge job will be triggered by files merged in the repo and will execute a release.
  2. Tech team needs to add "{project-name}-gerrit-release-jobs" to their ci-management yaml files. 
    1. This group introduces "gerrit-release-verify" and "gerrit-release-merge"
  3. Once a release candidate is build using gerrit-maven-stage, a new file will be posted describing the release.
    1. This file needs to be located in the root repo under a "releases" folder.
    2. An example can be viewed here: https://github.com/lfit/releng-global-jjb/blob/master/docs/jjb/lf-release-jobs.rst 
      1. Name of the file should match the semantic version of the release being publihed. (For example: releases/1.0.0.yaml)
      2. distribution_type: 'maven'  (Future expansion will allow "container" to be provided"
      3. version: '#.#.#' (Release semantic version)
      4. project: 'project-name' (Project name, for example 'ccsdk-parent')
      5. log-dir: 'pointer_to_maven_stage_job/build_number/' (for example: 'ccsdk-parent-maven-stage-master/2/')
      6. maven_central_url: 'oss.sonatype.org' ( Optional, in case the team want's to publish to Maven Central)
  4. This file will trigger "{project-name}-release-verify-{stream}"
    1. This job can also be triggered using the comment "recheck|reverify"
    2. The verify job will make sure the release file contains the needed information and that the candidate exists.
  5. Tech team needs to +2 this new change and merge it. Please do not override any -1 Verify from Jenkins.
  6. The merge will trigger "{project-name}-release-merge-{stream}"
    1. This job can also be triggered using the comment "remerge"
    2. This job will push the release and tag the repo.