Merge "Add release.sh, a script for creating releases"
This commit is contained in:
Zuul
Gerrit Code Review
commit
2aeb134390
|
|
@ -10,4 +10,5 @@ Kayobe Development Guide
|
|||
automated
|
||||
development
|
||||
testing
|
||||
releases
|
||||
contributing
|
||||
|
|
|
|||
|
|
@ -0,0 +1,111 @@
|
|||
========
|
||||
Releases
|
||||
========
|
||||
|
||||
The `project creator's guide
|
||||
<https://docs.openstack.org/infra/manual/drivers.html#release-management>`__
|
||||
provides information on release management. As Kayobe is not an official
|
||||
project, it cannot use the official release tooling in the
|
||||
``openstack/releases`` repository.
|
||||
|
||||
There are various `useful files
|
||||
<http://git.openstack.org/cgit/openstack-infra/project-config/tree/roles/copy-release-tools-scripts/files/release-tools/>`__
|
||||
in the ``openstack-infra/project-config`` repository. In particular, see the
|
||||
``releases.sh`` and ``make_branch.sh`` scripts.
|
||||
|
||||
Preparing for a release
|
||||
=======================
|
||||
|
||||
Synchronise kayobe-config
|
||||
-------------------------
|
||||
|
||||
Ensure that configuration defaults in ``kayobe-config`` are in sync with those
|
||||
under ``etc/kayobe`` in ``kayobe``. This can be done via:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
cp -aR kayobe/etc/kayobe/* kayobe-config/etc/kayobe
|
||||
|
||||
Commit the changes and submit for review.
|
||||
|
||||
Synchronise kayobe-config-dev
|
||||
-----------------------------
|
||||
|
||||
Ensure that configuration defaults in ``kayobe-config-dev`` are in sync with
|
||||
those in ``kayobe-config``. This requires a little more care, since some
|
||||
configuration options have been changed from the defaults. Choose a method to
|
||||
suit you and be careful not to lose any configuration.
|
||||
|
||||
Commit the changes and submit for review.
|
||||
|
||||
Add a prelude to release notes
|
||||
------------------------------
|
||||
|
||||
It's possible to add a prelude to the release notes for a particular release
|
||||
using a ``prelude`` section in a ``reno`` note.
|
||||
|
||||
Creating a stable branch
|
||||
========================
|
||||
|
||||
Stable branches should be cut for each Kayobe deliverable (``kayobe``,
|
||||
``kayobe-config``, ``kayobe-config-dev``).
|
||||
|
||||
To create a branch ``<new branch>`` at commit ``<ref>``:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
cd /path/to/repo
|
||||
git checkout -b <new branch> <ref>
|
||||
git review -s
|
||||
git push gerrit <new branch>
|
||||
|
||||
After creating the branch, on the new branch:
|
||||
|
||||
* update the ``.gitreview`` file on the new branch, for example:
|
||||
https://review.openstack.org/609735
|
||||
* update the references to upper-constraints to use the stable branch,
|
||||
For example https://review.openstack.org/#/c/568804.
|
||||
|
||||
For the kayobe repo only, on the master branch:
|
||||
|
||||
* update the release notes for the new release series:
|
||||
https://review.openstack.org/609742
|
||||
|
||||
Creating a release
|
||||
==================
|
||||
|
||||
Prerequisites
|
||||
-------------
|
||||
|
||||
Creating a signed tagged release requires a GPG key to be used. There are
|
||||
various resources for how to set this up, including
|
||||
https://help.ubuntu.com/community/GnuPrivacyGuardHowto. Your default Gerrit
|
||||
email should be added to the key, and the key should be trusted ultimately, see
|
||||
https://wiki.openstack.org/wiki/Oslo/ReleaseProcess#Setting_Up_GPG for
|
||||
information.
|
||||
|
||||
Tagging a release
|
||||
-----------------
|
||||
|
||||
Tags should be created for each deliverable (``kayobe``, ``kayobe-config``,
|
||||
``kayobe-config-dev``). Currently the same version is used for each.
|
||||
|
||||
The ``tools/release.sh`` script in the ``kayobe`` repository can be used to tag
|
||||
a release and push it to Gerrit. For example, to tag and release the ``kayobe``
|
||||
deliverable version ``4.0.0`` in the Queens series from the tip of the
|
||||
``stable/queens`` branch:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
./tools/release.sh kayobe 4.0.0 origin/stable/queens queens
|
||||
|
||||
Post-release activites
|
||||
----------------------
|
||||
|
||||
An email will be sent to the release-announce mailing list about the new
|
||||
release.
|
||||
|
||||
.. TODO: Setup RTD integration for release notes.
|
||||
|
||||
The release notes need to be rebuilt manually since there is no readthedocs
|
||||
webhook integration for these yet.
|
||||
|
|
@ -0,0 +1,64 @@
|
|||
#!/bin/bash
|
||||
|
||||
# Script to create a tagged release of a deliverable and push the tag to
|
||||
# Gerrit.
|
||||
|
||||
set -eu
|
||||
|
||||
function usage {
|
||||
echo "Usage"
|
||||
echo "$0 <repo> <version> <ref> <series>"
|
||||
echo
|
||||
echo "Example:"
|
||||
echo "$0 kayobe 4.0.0 origin/stable/queens queens"
|
||||
}
|
||||
|
||||
function get_last_tag {
|
||||
# Print the most recent tag for a ref. If no ref is specified, the
|
||||
# currently checked out branch is examined.
|
||||
local ref="$1"
|
||||
if ! git describe --abbrev=0 --first-parent ${ref} >/dev/null 2>&1; then
|
||||
echo ""
|
||||
else
|
||||
git describe --abbrev=0 --first-parent ${ref}
|
||||
fi
|
||||
}
|
||||
|
||||
[[ $# -eq 4 ]] || (usage; exit 1)
|
||||
|
||||
REPO=$1
|
||||
VERSION=$2
|
||||
REF=$3
|
||||
SERIES=$4
|
||||
RELEASETYPE=release
|
||||
|
||||
[[ -n $REPO ]] || (echo "Repo not specified"; exit 1)
|
||||
[[ -n $VERSION ]] || (echo "Version not specified"; exit 1)
|
||||
[[ -n $REF ]] || (echo "Ref not specified"; exit 1)
|
||||
[[ -n $SERIES ]] || (echo "Series not specified"; exit 1)
|
||||
|
||||
TARGETSHA=`git log -1 $REF --format='%H'`
|
||||
|
||||
# Determine the most recent tag before we add the new one.
|
||||
PREVIOUS=$(get_last_tag $TARGETSHA)
|
||||
|
||||
echo "Tagging $TARGETSHA as $VERSION"
|
||||
if git show-ref "$VERSION"; then
|
||||
echo "$REPO already has a version $VERSION tag, skipping further processing"
|
||||
continue
|
||||
fi
|
||||
|
||||
# WARNING(mgoddard): announce.sh expects to be able to parse this
|
||||
# commit message, so if you change the format you may have to
|
||||
# update announce.sh as well.
|
||||
TAGMSG="$REPO $VERSION $RELEASETYPE
|
||||
|
||||
meta:version: $VERSION
|
||||
meta:diff-start: -
|
||||
meta:series: $SERIES
|
||||
meta:release-type: $RELEASETYPE
|
||||
meta:pypi: no
|
||||
meta:first: no
|
||||
"
|
||||
git tag -m "$TAGMSG" -s "$VERSION" $TARGETSHA
|
||||
git push gerrit "$VERSION"
|
||||
Loading…
Reference in New Issue