Per best practices, explicitly use the python3 executable rather than
assuming the platform with have a "python" executable that maps to
python3.
https://www.python.org/dev/peps/pep-0394/
Change-Id: I39b8a1013a891f4570f374d8faa3cfa2ecaf3347
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
All releases are announced to the release-announce ML, except
Release candidates, which were still sent to openstack-discuss.
The rationale was that RCs should be announced to a developers
list rather than a downstream consumers list, so that they trigger
testing. But that is less true now that there is a single -discuss
list, where they generate a lot of noise around RC1, without
triggering any additional testing. They also confuse some downstream
consumers which expect those to go to the usual release announce list.
This patch removes the exception and makes sure we send all RC
announces to the release-announce list.
Change-Id: Id33dba37b4d53962a2170ec401499fe3dd2e24bf
We *know* that requirements will have a stable/train branch soon; make
sure clients don't go caching the redirect to master.
Change-Id: I8507d86e4f553b698163be61665267d42e033d91
Related-Change: Ia2e8c46c27ac97217576afdd1677efba4b99fc37
This allows us to get the list of cycle based projects that have not
branched yet, limited to the ones that are not trailing the actual
release.
list-deliverables --series train --no-stable-branch --cycle-based-no-trailing
Change-Id: Ice9eec1ca086bcf6a642146da74793b0699dbc94
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
The template still points to old cgit formed urls.
This is a problem, as those are 404 nowadays.
This should fix it.
Change-Id: Ic04cf3b8a46b70e3a5fe0260d022838869f037de
We now track explicit tarball base names at a top level under
repository-settings instead of per release. The only time it should be
needed per release is if a project changes their package name part way
through the cycle.
Since most teams are now publishing to pypi and have worked through
needing to rename their packages, it should be safe to update
new-release to not include the tarball-base override per individual
project in a release.
Change-Id: If1c77e358b48113a7fb4d7a48ed8d31841ab9419
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Tempest plugins do not branch, therefore we do not need to enforce that
the minor version is incremented to leave room for stable releases.
Change-Id: I22ba5cb42070b5a450617872de2da337b327de1c
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
The YAML 1.2 spec was released in 2009. It's probably been enough time
that it's safe to move to it.
The only issue for out YAML usage was 1.2 dropped the use of Yes, No, On,
and Off as valid boolean values.
Change-Id: I608e09d219379e00cca15c5ff165bb63aecfe9f2
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Some "other" deliverables like tempest and patrole never
create stable branches. This allows to clearly mark such
deliverables and add a corner case in validation tests.
Change-Id: I2f6414d0f71baad58335702743f2180f8da3273f
Allow list_deliverables to filter output to list only deliverables
that have not been released since a given date (--unreleased-since).
This will be useful to compile list of libraries to autorelease at
milestones, or check for cycle-with-intermediary services that may
need a refresh release.
Additionally, if --show-dates is provided, the dates for last releases
(or all releases if -a option is provided) will be retrieved (and
displayed if in verbose mode).
Retrieving release dates is done through querying opendev's API for
tag references and looking at committer dates, so it requires Internet
access and increases command run time. It is only enabled if
--show_dates or --unreleased-since are enabled.
Task: 35684
Change-Id: I00aff6703e85a00572edb363973c92b883a79456
Checks have been added for additional files besides the deliverables. A
specific deliverable file can be specified with the command, but even
when doing so, the updates would still check these other data files.
This updates the handling to only check those files if one was not
provided.
Also small pep257 update.
Change-Id: I80e96319d8f7377db67a336d5c1a5569d75007a1
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
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>
The Ruamel library has better support for modifying YAML while keeping
things like comments. This updates our yamlutil module to use
ruamel.yaml instead of PyYAML.
Story: 2002908
Task: 22880
Change-Id: I4ac66c9e3e40780b588377c1dfe42511eed231a3
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
The list of tags associated with a deliverable is rarely useful, and yet
takes up massive horizontal space in verbose mode. In preparation for
adding more columns, make display of tags optional.
Change-Id: Id0946a6bbf86e79a4ba2a613c6950e3dd352cf80
For things like tempest-plugins, the cycle-with-intermediary model
is a bit overkill, especially now that we encourage multiple
intermediary releases to qualify.
Introduce a new 'cycle-automatic' model for deliverables that only
need to be released once, automatically at the end of the cycle.
This is limited to "other" or "tempest-plugin" deliverables.
Task: 31025
Change-Id: I83ff63cef18ae297013c3761a373078e580cf58b
Recent merging of the liaison-loading code in list-changes makes
most list-changes job fail due to error in YAML loading code.
Beyond that YAML loading issue, the code assumes getting a dictionary
with team names as keys and an array of liaisons dictionary as values.
Fix the release_liaisons.yaml and schema to match.
Change-Id: I94fa41862d37aaf0535d64afd00b2bd55bb4649a
Currently validation considers it valid to propose final versions
on a cycle-with-rc model without RC first:
https://review.opendev.org/#/c/613444/2
Relying on human review to catch that sounds risky. Let's fix it.
Change-Id: Id06794f165f0c852fb62dcacd53058bdc756899e
Task: 27762
Now that the release liaison info lives in data/release_liaisons.yaml,
we don't need to pull from the wiki. This patch also adds a schema
to verify the release_liaions.yaml is formatted correctly.
Story: 2005702
Task: 33639
Task: 33733
Change-Id: Ic4de16c26bb1a4fb878b86d2bd9c59bf5f54d11d
Adding liaisons to deliverables where there is a liasion listed here:
https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management
Also creates a data dir to put the non deliverable files that were in the
deliverables dir elsewhere and updates filepaths to reflect the change.
Story: 2005702
Task: 31024
Change-Id: Idc5f4b29dd375465b21d678fa8503cbd8d6d3eb6
Currently constraint redirectiones that point to EOL releases don't work
as expected due to gitea needed to differentiate between tags and
branches. Rather than fix, and rely on multiple redirects lets just
craft 301's that point to the correct gitea url.
This means we now need to know when a target is a branch or tag but
that's pretty simple to intuit given our deliverable structure.
Change-Id: Ife030f8ee7b5d204b054f99e920a675f7d92da69
If a project is independent, the tag names will not match the series
name.
Change-Id: Ib85bc9bc9747a7dbe9fc1d59ca893de4ce0d11bf
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
There are many references to review.openstack.org, and while the
redirect should work, we can also go ahead and fix them.
Change-Id: I0d46b1a4e00c1775ea5e38d39e87bed99f6bbb2e
Argument naming ambiguity led to grabbing the wrong value. This updates
repo name handling to grab from the right input.
Change-Id: I4987fc012a07344cbc4290e33eae5b772270eb07
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
After we tagged a realease EM git describe on a branch will include that
tag and as it contains a '-' it breaks the partition() we're using to
get the tag[1].
Switch to using a re rather than the simple partition.
(venv) [tony@thor releases]$ ipython
Python 3.7.3 (default, Mar 27 2019, 13:41:07)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.4.0 -- An enhanced Interactive Python. Type '?' for help.
In [1]: import openstack_releases.cmds.list_changes
In [2]: workdir = '/home/tony/projects/openstack'
In [3]: repo = 'openstack/python-manilaclient'
In [4]: openstack_releases.cmds.list_changes.git_list_existing_branches(workdir, repo)
All Branches with Version Numbers
---------------------------------
feature/add-constraints-support 1.11.0-36-g7134e3c 1.11.0 2 years, 8 months ago
master 1.27.0-10-g05a3f4d 1.27.0 6 months ago
review/openstack_release_bot/create-stein 1.27.0-2-g31608cf 1.27.0 6 months ago
remotes/gerrit/master 1.27.0-10-g05a3f4d 1.27.0 6 months ago
fatal: ambiguous argument 'ocata': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
remotes/gerrit/stable/ocata ocata-em-5-g22e9c42 ocata
remotes/gerrit/stable/pike 1.17.4 1.17.4 7 months ago
remotes/gerrit/stable/queens 1.21.1-6-g02d6234 1.21.1 1 year, 1 month ago
remotes/gerrit/stable/rocky 1.24.1-9-g816bfc8 1.24.1 9 months ago
remotes/gerrit/stable/stein 1.27.0-3-g7430f4c 1.27.0 6 months ago
remotes/origin/master 1.27.0-10-g05a3f4d 1.27.0 6 months ago
fatal: ambiguous argument 'ocata': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
remotes/origin/stable/ocata ocata-em-5-g22e9c42 ocata
remotes/origin/stable/pike 1.17.4 1.17.4 7 months ago
remotes/origin/stable/queens 1.21.1-6-g02d6234 1.21.1 1 year, 1 month ago
remotes/origin/stable/rocky 1.24.1-9-g816bfc8 1.24.1 9 months ago
remotes/origin/stable/stein 1.27.0-3-g7430f4c 1.27.0 6 months ago
In [5]: from imp import reload
In [6]: reload(openstack_releases.cmds.list_changes)
Out[6]: <module 'openstack_releases.cmds.list_changes' from '/home/tony/projects/openstack/openstack/releases/openstack_releases/cmds/list_changes.py'>
In [7]: openstack_releases.cmds.list_changes.git_list_existing_branches(workdir, repo)
All Branches with Version Numbers
---------------------------------
feature/add-constraints-support 1.11.0-36-g7134e3c 1.11.0 2 years, 8 months ago
master 1.27.0-10-g05a3f4d 1.27.0 6 months ago
review/openstack_release_bot/create-stein 1.27.0-2-g31608cf 1.27.0 6 months ago
remotes/gerrit/master 1.27.0-10-g05a3f4d 1.27.0 6 months ago
remotes/gerrit/stable/ocata ocata-em-5-g22e9c42 ocata-em 2 years, 3 months ago
remotes/gerrit/stable/pike 1.17.4
remotes/gerrit/stable/queens 1.21.1-6-g02d6234 1.21.1 1 year, 1 month ago
remotes/gerrit/stable/rocky 1.24.1-9-g816bfc8 1.24.1 9 months ago
remotes/gerrit/stable/stein 1.27.0-3-g7430f4c 1.27.0 6 months ago
remotes/origin/master 1.27.0-10-g05a3f4d 1.27.0 6 months ago
remotes/origin/stable/ocata ocata-em-5-g22e9c42 ocata-em 2 years, 3 months ago
remotes/origin/stable/pike 1.17.4
remotes/origin/stable/queens 1.21.1-6-g02d6234 1.21.1 1 year, 1 month ago
remotes/origin/stable/rocky 1.24.1-9-g816bfc8 1.24.1 9 months ago
remotes/origin/stable/stein 1.27.0-3-g7430f4c 1.27.0 6 months ago
[1] http://logs.openstack.org/75/652775/2/check/releases-tox-list-changes/92b219a/job-output.txt.gz#_2019-04-16_14_25_50_377843
Change-Id: I6a6cf9110a737204e332c60004f72a68b770d1e7
We use release-types as a way to verify that versions are compatible and
if needed reflected accurately in the code (puppet, xstatic). If one
isn't set explicitly then we assume python-service.
In certain circumstances (anything other than the first release in a
series) we also perform python specific requirements checking on all
'python' types.
Add a new 'generic' type that uses the same rules to validate version
numbers but wont run any python specific checks.
We need this a projects (like monasca-thresh) will fail the requirements
check for 2nd or greater releases[1].
An alternate would be to have the requirements code check if setup.py
exists before calling it but that seems like the wrong layer to me.
[1] http://logs.openstack.org/54/652854/1/check/openstack-tox-validate/80df01c/job-output.txt.gz#_2019-04-16_06_08_00_636538
Change-Id: I3fcde5eb266f954fddb6871ce8690b93b8fd7a8d
The list-changes job would fail to parse deliverable files with the
error "WARNING: Unable to parse $repo $series deliverable file" due to
the repo name being passed in with the leading openstack/ namespace.
This is common code used by list-changes and release-notes. In
list-changes we have the actual name of the deliverable file, so just
use that if it is available.
Also makes sure that cases were we expect just the repo name without
namespace only get what is expected.
Change-Id: Ib7526fc66d05530c2c2c722284c1d64a5242e419
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Updates to use opendev.org or published documentation.
Change-Id: I0bd488b25d1259bce3f723a6c58283fdf670e721
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
This updates the new-release command to use the last release for normal
repos when transitioning to -em, but grabbing the current HEAD when
tagging "release-model: untagged" deliverables.
Change-Id: I42acb74d033429a72946fda136f87b4ccaefb220
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>