Release requests and history tracking
Go to file
Hervé Beraud 9504e96b5d Fix validation to ensure that first release of series isn't a bugfix
We recently observed that this check was skipped. Indeed it was
possible to propose a bugfix version on the first release of a series
without facing validation errors [1].

The described situation was allowed by checks that we introduced
during Wallaby [2]. Those was designed to ensure that we can
build sdist from the proposed tag. Indeed, they temporarly created
the new git tag to build sdist from it. However we never delete this
tag after our tests so this temporary tag is see as an existing tag
and so that led us to the observed bug.

Our validation check that the first version number of series isn't a
bugfix after it tried to build the sdist from the new tag, so, without
this patch the tag newly created by the sdist check remains available
in the repo, and so a couple of next checks are skipped, including the
validation of the version number, because these checks are decorated
to ignore existing tags.

Indeed the function decorated with `skip_existing_tags` detect this
temporary tag as an existing tag, so, the decorated functions are
skipped.

We should notice that it surely impacted other checks in the same manner.
Indeed, all validation functions decorated with this function
`skip_existing_tags` are impacted by this bug.
Hopefully it didn't have too much side effects.

These changes delete the temporary tag after usage to ensure to restore
the initial environment and to stop skipping next checks.

[1] https://review.opendev.org/c/openstack/releases/+/795836
[2] 80652b5232

Change-Id: I5d9024528d08487a7582e0a0e73576b22708a6cf
2021-06-17 13:41:12 +02:00
data Merge "adding new email for keystone's release liaison" 2021-06-10 09:03:43 +00:00
deliverables Merge "Release oslo.limit for Xena" 2021-06-10 11:38:06 +00:00
doc List the Xena cycle signing key as current 2021-05-06 01:11:26 +00:00
openstack_releases Fix validation to ensure that first release of series isn't a bugfix 2021-06-17 13:41:12 +02:00
templates Remove unused RC templates 2019-09-23 18:04:44 +02:00
tools Fix list_eol_stale_branches.sh to list only stale branches 2021-05-03 21:51:51 +02:00
.gitignore Switch to stestr 2018-07-10 10:38:33 +07:00
.gitreview OpenDev Migration Patch 2019-04-19 19:37:48 +00:00
.stestr.conf Switch to stestr 2018-07-10 10:38:33 +07:00
.zuul.yaml Switch to victoria job template 2020-06-02 14:28:30 -05:00
bindep.txt Cleanup bindep packages 2020-04-11 15:57:21 -05:00
CONTRIBUTING.rst Document tag pipeline jobs in contributor doc 2019-06-06 12:10:45 +02:00
LICENSE Add top level LICENSE file 2018-10-17 10:36:04 +11:00
README.rst moving to OFTC 2021-05-27 13:53:16 +02:00
requirements.txt add reno semver-next to the list-changes output 2020-09-03 08:34:49 -04:00
setup.cfg setup.cfg: Replace dashes with underscores 2021-05-04 17:28:05 +08:00
setup.py [Trivial] Remove executable privilege of setup.py 2016-05-09 16:38:37 +00:00
test-requirements.txt Update to latest hacking for pep8 checks 2020-07-27 16:33:03 -05:00
tox.ini Use py3 as the default runtime for tox 2021-04-20 14:57:51 +08:00
watched_queries.yml Rename review.openstack.org to review.opendev.org 2019-05-12 04:33:25 +08:00
yamllint.yml add linter rules for vertical whitespace 2017-07-31 17:26:33 -04:00

OpenStack Releases

image

This repository is used to drive release automation for OpenStack release deliverables, ultimately publishing them on the https://releases.openstack.org/ website.

Changes to this repository are proposed using Gerrit at https://review.opendev.org. This repository is managed by the OpenStack Release Management team.

For more information on how to use this repository, please read our reference documentation.

Who should use this repository

All official OpenStack software should go through the OpenStack Release Management team team to produce releases. Exceptions to this rule are granted by the Technical Committee and documented in the openstack/governance repository ('release-management' key in reference/projects.yaml).

Deliverables managed by teams not under OpenStack governance should follow the tagging instructions in the infra manual.

More information

You can reach the Release Management team on the #openstack-release channel on OFTC IRC <https://www.oftc.net/>, or by sending an email with '[release]' as a subject prefix to the openstack-discuss mailing-list.