Jump to: navigation, search

Difference between revisions of "QA/releases"

< QA
(tempest)
(Update the release process for all the QA projects with example and steps.)
Line 1: Line 1:
= Projects with only Branches =
+
OpenStack QA releases its tooling as per each tool release model and also needs to take care of the new branch set on devstack and grenade.
 
+
This page explain the process and tasks QA team needs to do on every OpenStack release.  
For the most part Devstack and Grenade only have branches, which need
 
to be cut when other projects get '''stable/*''' branches during a
 
release.
 
 
 
== Devstack ==
 
 
 
The branch process for Devstack is as follows:
 
 
 
# Wait for stable/branch to exist on the bulk of projects in devstack repo
 
# Ask '''Release Team''' to create a '''stable/foo''' branch
 
# Update '''.gitreview''' and '''stackrc''' in '''stable/foo''' to reference the new branch
 
# Update '''lib/tempest''' to hardcode max microversions and extensions
 
 
 
== Grenade ==
 
 
 
The branch process for Grenade is as follows:
 
 
 
# Wait for stable/branch to exist on Devstack
 
# Ask '''Release Team''' to create a '''stable/foo''' branch
 
# Update '''.gitreview''' and '''grenaderc''' in '''stable/foo''' to reference the new branch
 
## Example: https://review.openstack.org/129645
 
# Update '''grenaderc''' in '''master''' to reference the new branch
 
## Example: https://review.openstack.org/128959
 
# Update '''devstack-gate''' logic to use the new branches
 
## Example: https://review.openstack.org/128974/
 
  
 
= Project Releases =
 
= Project Releases =
  
== tempest ==
+
== Project with release mode: cycle-with-intermediary ==
  
With the start of branchless tempest there are no long any tempest releases, but instead incremental tags for each OpenStack release milestones. The tag should be incremented to coincide with either a new OpenStack release, or the EOL of a supported stable branch. For example, the tempest-2 tag was added at the Juno release and was used to mark adding support for the Kilo release. The next tag tempest-3 will be used to either signify the start of L development or the EOL of icehouse, whichever occurs first.
+
=== Tempest ===
In addition, the tempest repository contains library interfaces based on https://specs.openstack.org/openstack/qa-specs/specs/tempest/implemented/reintegrate-tempest-lib.html
 
So we are releasing new tags in the middle of releases also for new library interfaces. Please see https://github.com/openstack/tempest/releases/tag/12.1.0 as the sample.
 
  
The procedure for pushing a new tempest tag is:
+
* Step1: Add Release note to mark the release
 +
** Example:
 +
*** Intermediate release https://review.openstack.org/#/c/514873/2
 +
*** Cycle release –https://review.opendev.org/#/c/685401/
 +
*** EOL stable release – https://review.opendev.org/#/c/703255/
 +
* Step2: Push release tag to openstack/release repo
 +
** Example:
 +
*** Intermediate - https://review.opendev.org/#/c/688613/
 +
*** Cycle release- https://review.opendev.org/#/c/685406/
 +
* Step3: Add release notes page after release patch is merged
 +
** Example:
 +
*** Cycle Release- https://review.opendev.org/#/c/687123/
 +
* Step4: Add releasenotes page link in openstck/release
 +
** Example: https://review.opendev.org/#/c/687619/
 +
* Step5: Remove the End of Support branch job from tempest gate if release is for end of support for any stable branch
 +
** Example: https://review.opendev.org/#/c/703646/
  
* Check the format of the existing tags
+
=== Patrole ===
  
        $ git tag -n
+
* Step1: Add Release note to mark the release
 +
** Example: https://review.opendev.org/#/c/685429/
 +
* Step2: Push release tag to openstack/release repo
 +
** Example: https://review.opendev.org/#/c/685430/
 +
* Step3: Add release notes page after release patch is merged
 +
** Example: https://review.opendev.org/#/c/687124/
 +
* Step4: Add releasenotes page link in openstck/release
 +
** Example: https://review.opendev.org/#/c/687582/
 +
* Step5: Remove the End of Support branch job from tempest gate if release is for end of support for any stable branch:
  
* Check a new reno before tagging. You can see a new reno on the first report
+
== Project with release mode: independent ==
  
        $ reno report .
+
Below projects are with independent release and not associated with OpenStack cycle release.
  
You can check it from http://docs.openstack.org/releasenotes/tempest/unreleased.html also
+
* hacking
 +
** Example: https://review.opendev.org/#/c/715578/
 +
* os-testr
 +
** Example: https://review.opendev.org/#/c/713142/
 +
* bashate
 +
** Example: https://review.opendev.org/#/c/710560/
 +
* devstack-tools
 +
** Example: https://review.opendev.org/#/c/710561/
 +
* eslint-config-openstack
  
* Add a reno for releasing a new tag like https://review.openstack.org/#/c/383442/
+
== Project with no release==
  
* Once the version bump is in master you can tag the release and push it to gerrit with:
+
Below projects are with no release and maintained as master version only.
  
        $ git tag -s (version number like "12.1.0")
+
* coverage2sql
        $ git push gerrit (version number like "12.1.0")
+
* devstack-plugin-ceph
 +
* devstack-plugin-cookiecutter
 +
* devstack-plugin-open-cas
 +
* devstack-plugin-nfs
 +
* devstack-vagrant
 +
* karma-subunit-reporter
 +
* openstack-health
 +
* os-performance-tools
 +
* stackviz
 +
* tempest-stress
 +
* tempest-plugin-cookiecutter
  
this will add the signed tag to the git repo and generate a tarball and store it here: http://tarballs.openstack.org/tempest/
 
  
If you face the following problem, you need to run "$ git review -s" before pushing:
+
= Projects with only Branches =
  
      $ git push gerrit 14.0.0
+
For the most part, Devstack and Grenade only have branches, which need to be cut when other projects get '''stable/*''' branches during a
      fatal: 'gerrit' does not appear to be a git repository
+
release.
      fatal: Could not read from remote repository.
 
      Please make sure you have the correct access rights
 
      and the repository exists.
 
 
 
== tempest-lib ==
 
 
 
'''NOTE: tempest-lib  itself has been deprecated now, so we never need to release a new tempet-lib anymore'''
 
 
 
== Hacking ==
 
 
 
Versioning: http://docs.openstack.org/developer/hacking/readme.html#versioning
 
 
 
Hacking has a branch for every major.minor release. For example: 0.9.x and 0.8.x. The process for cutting a new major or minor release involves creating a new branch and pushing a tag (major.minor.0). At that point patches that fit the versioning requirements can be backported to the stable branch for maintenance releases.
 
 
 
The releasing way is the same as Tempest one.
 
 
 
== eslint-config-openstack ==
 
 
 
This project follows the release model of Hacking (above), with a branch for every major.minor release (ex: 0.9.x and 0.8.x). Please refer to the above for process and procedure.
 
 
 
To perform a release, please first install npm on your system. Then, perform the following steps:
 
 
 
    # Check out the most recent master.
 
    git checkout master; git pull;
 
  
    # Ask NPM to update the package version, and tag the release.
+
* Devstack
    npm version (major|minor|patch)
+
** Step1: Wait for stable/* branch to exist on the projects in Devstack repo
 +
** Step2: Propose to openstack/releases to create a stable/foo branch for Devstack
 +
*** Example: https://review.opendev.org/#/c/685400/
 +
** Step3: Update .gitreview for stable/foo – patch from OpenStack Release Bot
 +
*** Example: https://review.openstack.org/#/c/647855/
 +
** Step4: Update branches for stable/foo
 +
*** Example: https://review.openstack.org/#/c/647867/
 +
** Step5: Update DEVSTACK_SERIES on master Devstack
 +
*** Example: https://review.opendev.org/#/c/687112/ 
 +
** Step6: Update lib/tempest to hardcode max microversions and extensions on stable/foo
 +
*** Example:
 +
**** https://review.opendev.org/#/c/687115/
 +
**** https://review.opendev.org/#/c/687176/
 +
** Step7: After Devstack has been branched.  Add a new stable branch job in the Tempest pipeline.
 +
*** Example: https://review.opendev.org/#/c/686781
 +
** Step8: After Devstack has been branched.  Configure devstack-gate to run the new stable branch jobs.
 +
*** Example: https://review.opendev.org/#/c/686776/
 +
** Step9: After Devstack has been branched.  Add the new stable branch to the list of branches in the periodic-stable job templates in openstack-zuul-jobs.
 +
*** Example: https://review.opendev.org/#/c/687122/
  
    # Push the new tag to gerrit
+
* Grenade
    git push --tags
+
** Step1: Wait for stable/branch to exist on Devstack
 +
** Step2: Propose  to openstack/releases to create a stable/foo branch
 +
*** Example: https://review.opendev.org/#/c/686771/
 +
** Step3: Update .gitreview for stable/x – from OpenStack Release Bot
 +
*** Example: https://review.opendev.org/#/c/686991/
 +
** Step5: Update devstack-gate logic to use the new branches
 +
*** Example: new- https://review.openstack.org/#/c/591594/
  
    # Request for a code review on the new version tag.
+
* devstack-plugin-container: hanled by devstack-plugin-container team.
    git review
 
  
    # Ask NPM to publish the tag to npmjs.com
+
Once all done then you deserve to go for beer \o/
    # (This step will be deprecated by https://review.openstack.org/#/c/199725/)
 
    npm publish
 

Revision as of 22:16, 20 April 2020

OpenStack QA releases its tooling as per each tool release model and also needs to take care of the new branch set on devstack and grenade. This page explain the process and tasks QA team needs to do on every OpenStack release.

Project Releases

Project with release mode: cycle-with-intermediary

Tempest

Patrole

Project with release mode: independent

Below projects are with independent release and not associated with OpenStack cycle release.

Project with no release

Below projects are with no release and maintained as master version only.

  • coverage2sql
  • devstack-plugin-ceph
  • devstack-plugin-cookiecutter
  • devstack-plugin-open-cas
  • devstack-plugin-nfs
  • devstack-vagrant
  • karma-subunit-reporter
  • openstack-health
  • os-performance-tools
  • stackviz
  • tempest-stress
  • tempest-plugin-cookiecutter


Projects with only Branches

For the most part, Devstack and Grenade only have branches, which need to be cut when other projects get stable/* branches during a release.

  • devstack-plugin-container: hanled by devstack-plugin-container team.

Once all done then you deserve to go for beer \o/