aa3ab893c2
If we make modifications to a deliverable file for whatever reason and that series is EOL, the validation code would still check that branches existed and therefore fail. The stable/$series branch most likely is deleted after going EOL, so the validation code would think there was a need for a new branch to be created, then fail if the last release done was not the same point as the branch. This updates the validation logic to check up front if the deliverable is EOL and skip these checks. Change-Id: Ib5be3c0ba7283021301d278fcb362432f9a7d5cb Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com> |
||
|---|---|---|
| data | ||
| deliverables | ||
| doc | ||
| openstack_releases | ||
| templates | ||
| tools | ||
| .gitignore | ||
| .gitreview | ||
| .stestr.conf | ||
| .zuul.yaml | ||
| bindep.txt | ||
| CONTRIBUTING.rst | ||
| LICENSE | ||
| README.rst | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
| watched_queries.yml | ||
| yamllint.yml | ||
Using This Repository
All official OpenStack software should go through the 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).
This repository is used to track release requests. Releases are managed using groups of "deliverables", made up of individual project repositories sharing a Launchpad group and a version number history. Many deliverables will only have one constituent project repository.
The repository is managed by the Release Management team.
Refer to the reference documentation for more details
Deliverables managed by teams not under OpenStack governance should follow the tagging instructions in the infra manual.