project-config/jenkins/scripts/release-tools
Doug Hellmann bf142fa7b7 make release script repo cloning function more resilient
The release scripts had been assuming that a valid gerrit user was
always configured already, but this is not necessarily the case on all
nodes. Now that the constraint update job has moved to the proposal
nodes, we need to make the cloner code try to configure the gerrit user
if "git review -s" fails. We can't always take that step because it
would result in using the wrong user on the signing node and when users
run the scripts by hand (as we still do frequently to recover from
failures).

Change-Id: Ife8108f0bff4be9ab63befc5eff4289be78316f7
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
2016-12-21 15:14:00 -05:00
..
add_release_note_page.sh do not prompt before submitting multiple reviews 2016-09-15 08:39:26 -04:00
branch_from_yaml.sh add branch automation to the tag-releases job 2016-11-28 15:25:14 -05:00
functions make release script repo cloning function more resilient 2016-12-21 15:14:00 -05:00
launchpad_add_comment.py import the release tools that need to run on secure nodes 2016-06-21 15:55:15 -04:00
list_deliverable_branches.py add branch automation to the tag-releases job 2016-11-28 15:25:14 -05:00
list_deliverable_changes.py ignore deliverable files with no releases listed 2016-12-02 08:41:22 -05:00
make_branch.sh add branch automation to the tag-releases job 2016-11-28 15:25:14 -05:00
README.rst start a readme describing the release tools 2016-06-22 13:52:30 -04:00
release_from_yaml.sh No longer specify announce list in tag message 2016-11-16 17:02:30 +01:00
release.sh make release script repo cloning function more resilient 2016-12-21 15:14:00 -05:00
requirements.txt import the release tools that need to run on secure nodes 2016-06-21 15:55:15 -04:00
update_constraints.sh make release script repo cloning function more resilient 2016-12-21 15:14:00 -05:00

Release Tools

release_from_yaml.sh

This script takes YAML files describing deliverables to release (like those living in openstack/releases) and calls the release.sh script (see below) to apply the corresponding tags. It will create a tag for the last release mentioned in the file(s). You can point it to specific YAML files, or to a local git repository (in which case it will look at the files modified in the most recent commit).

Examples:

./release_from_yaml.sh ../openstack-releases deliverables/mitaka/nova.yaml

Call release.sh for all repositories mentioned in the last release added to ../openstack-releases/deliverables/mitaka/nova.yaml

./release_from_yaml.sh ../openstack-releases

Look into the git repository at ../openstack-releases for deliverable YAML files modified at the last commit, and call release.sh for all repositories mentioned on the last release in each such file.

release.sh

This script creates a tag on a given repository SHA and pushes it to Gerrit. Additionally it will add a message on Launchpad bugs that are mentioned as "closed" in git commit messages since the last tag on the same series.

Example:

./release.sh openstack/oslo.rootwrap mitaka 3.0.3 gerrit/master

Apply a 3.0.3 tag (associated to the mitaka series) to the gerrit master HEAD of the openstack/oslo.rootwrap reporitory, and add a comment for each closed bug mentioned in commit messages since the previous mitaka tag (3.0.2).

branch_from_yaml.sh

This script looks at the deliverable files to decide how to create stable branches.

$ branch_from_yaml.sh ~/repos/openstack/releases mitaka
$ branch_from_yaml.sh ~/repos/openstack/releases mitaka
$ branch_from_yaml.sh ~/repos/openstack/releases mitaka deliverables/_independent/openstack-ansible.yaml