24657889a3
Change-Id: Ic5b41116d16929a0cb6c47db614ca7eaa2cfcde8
180 lines
5.6 KiB
ReStructuredText
180 lines
5.6 KiB
ReStructuredText
::
|
|
|
|
Copyright 2015, Hewlett Packard Enterprise Development LP
|
|
|
|
This work is licensed under a Creative Commons Attribution 3.0
|
|
Unported License.
|
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
|
|
|
..
|
|
This template should be in ReSTructured text. Please do not delete
|
|
any of the sections in this template. If you have nothing to say
|
|
for a whole section, just write: "None". For help with syntax, see
|
|
http://sphinx-doc.org/rest.html To test out your formatting, see
|
|
http://www.tele3.cz/jbar/rest/rest.html
|
|
|
|
=============================================
|
|
Complete Reviewable Release Automation Work
|
|
=============================================
|
|
|
|
https://storyboard.openstack.org/#!/story/2000421
|
|
|
|
During Liberty we started building release tools to mostly automate a
|
|
process for reviewing release requests and then tagging releases (see
|
|
:doc:`centralize-release-tagging`). This spec describes the pieces
|
|
needed to complete that work so that when requests are merged the
|
|
release is tagged without human intervention.
|
|
|
|
Problem Description
|
|
===================
|
|
|
|
During Liberty we added tools to the openstack-infra/release-tools
|
|
repository to read the files in openstack/releases and publish
|
|
releases. Those tools only work correctly for libraries, and must be
|
|
run manually.
|
|
|
|
Proposed Change
|
|
===============
|
|
|
|
This cycle we need to expand support for all project types and
|
|
complete the automation so that the release tag is pushed to the
|
|
project repository by a job after the request is approved and merges
|
|
in the ``openstack/releases`` repository.
|
|
|
|
We also want to stop having the release tools update the bug and
|
|
blueprint status in Launchpad. Instead of updating the status of the
|
|
bug, we will leave a comment on the bug indicating when it was
|
|
released. Bug status should be updated to "Fix Released" when a patch
|
|
merges, instead of "Fix Committed". This will require updating the job
|
|
that runs when the release request merges in
|
|
``openstack/releases``.
|
|
|
|
A second job runs later to announce the new release, after the tarball
|
|
has been published. This job will run against the project repository,
|
|
so in order to ensure it has all of the information it needs, and to
|
|
ensure that there is a good record of the release activity, we will
|
|
store some data in the comment associated with the signed tag created
|
|
by the first job. We will need at least the series name so we can
|
|
determine the branch for the release history. We can assume zuul will
|
|
check out the project repository to the tagged commit, and determine
|
|
the current version from there.
|
|
|
|
Alternatives
|
|
------------
|
|
|
|
Continuing to tag releases by hand is causing delays in releases.
|
|
|
|
Implementation
|
|
==============
|
|
|
|
Assignee(s)
|
|
-----------
|
|
|
|
Primary assignee:
|
|
|
|
- doug-hellmann
|
|
- fungi
|
|
|
|
Gerrit Topic
|
|
------------
|
|
|
|
Use Gerrit topic "release-automation" for all patches related to this spec.
|
|
|
|
.. code-block:: bash
|
|
|
|
git-review -t release-automation
|
|
|
|
Work Items
|
|
----------
|
|
|
|
#. Update jeepyb to set the bug status to "Fix Committed" instead of
|
|
"Fix Released" (https://review.openstack.org/248922)
|
|
|
|
* Need to communicate this change so that projects are aware of the
|
|
process change
|
|
(http://lists.openstack.org/pipermail/openstack-dev/2015-November/080288.html)
|
|
|
|
#. Update the options in openstack-infra/project-config to remove the
|
|
redundant values setting jeepyb behavior to its new default
|
|
(https://review.openstack.org/248923)
|
|
|
|
#. Create a new script in openstack-infra/release-tools to find the
|
|
set of bugs mentioned as closed in the git commit messages for a
|
|
release and add comments to those bugs giving the version number
|
|
for when a fix for a bug was actually included in a
|
|
release. (http://git.openstack.org/cgit/openstack-infra/release-tools/tree/release.sh#n84)
|
|
|
|
#. Create a new script in openstack-infra/release-tools to be run as
|
|
part of the post-merge job for openstack/releases
|
|
(http://git.openstack.org/cgit/openstack-infra/release-tools/tree/release_from_yaml.sh)
|
|
|
|
That script needs to
|
|
|
|
* identify the changed deliverable files in a given commit
|
|
* determine the tags listed in the deliverable files that are not
|
|
present in the git repositories
|
|
* add the required signed tags to those repositories to trigger the
|
|
existing release process, including any metadata needed for
|
|
subsequent jobs (especially the series name)
|
|
* invoke the bug update script created above after scanning each
|
|
repository
|
|
|
|
Other notes from the summit discussion
|
|
|
|
* Requires support for GPG keys on the build machines, see
|
|
:doc:`artifact-signing`.
|
|
|
|
* Tag comments should include audit details like who requested the
|
|
release (author & committer of the change to openstack/releases),
|
|
a link back to that change-id, etc.
|
|
|
|
#. Set up a post-merge job for openstack/releases to run the script
|
|
created in the previous step.
|
|
|
|
#. Create a new script in openstack-infra/release-tools to be run
|
|
during the existing release build job (http://git.openstack.org/cgit/openstack-infra/release-tools/tree/announce.sh)
|
|
|
|
That script needs to
|
|
|
|
* generate and send release notes email based on the changes in
|
|
each release
|
|
|
|
#. Update the release build job to call the script created in the
|
|
previous step.
|
|
|
|
Repositories
|
|
------------
|
|
|
|
None
|
|
|
|
Servers
|
|
-------
|
|
|
|
None
|
|
|
|
DNS Entries
|
|
-----------
|
|
|
|
None
|
|
|
|
Documentation
|
|
-------------
|
|
|
|
When the work is done we'll announce it on the mailing list.
|
|
|
|
Security
|
|
--------
|
|
|
|
This work builds on the key management work in :doc:`artifact-signing`.
|
|
|
|
Testing
|
|
-------
|
|
|
|
We tested ``release_from_yaml.sh``, ``release.sh`` and ``announce.sh``
|
|
during the Mitaka 1 milestone.
|
|
|
|
Dependencies
|
|
============
|
|
|
|
This work builds on the key management work in :doc:`artifact-signing`.
|