We don't want to allow tagging EM if there were no releases. We also
want to make sure the -em tag is on the last official release that was
done.
Change-Id: I7afb3a52cf2ec47d8e0154b51825b500806aa590
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
There could be an issue in previous tagged releases due to external
factors. In that case, there is no way to fix that version.
Validation currently checks out the previous tag and creates an sdist in
order to compare requirements changes on bugfix version bumps only. In
the case where the previous release has an issue, just handle the
failure and move along.
Change-Id: I60db41a475c3a13359556198c0611489dffa4b3f
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
In releases.o.o we display signature links for all deliverables,
if the series is > Ocata or independent. Since some "independent"
deliverables predate the signature generation tooling, that results
in a number of "independent" deliverables displaying broken signature
links, which makes us look bad.
This adds a flag (skipped-sig) that can be set for independent
deliverables that did not have any signature generated (pre-Ocata), and
skips the signature link display if the flag is set.
As a practical example, this fixes broken links for PBR<2. Tony signed
up to automatically generate the others.
Change-Id: I44a49e3f08010a85c64673d2292528139eabcc99
Now that all the Contacts are an object we can just use __str__ to
format them and pass that to print rather than use a print_contact()
function
Change-Id: I6cce8c08eaa19c06695a044da59ba75e671f3005
get-contacts:
To extract the PTL/Liaison contact information from the governance data
/ release team data
tools/bulk_review.sh:
To manipulate a dirty working-tree and post as a single gerrit topic,
one change per team. Changes are unordered so any change can be merged
when it's ready/ approved by the appropriate team
Also enhance get-deliverable-owner: to detect file paths
Story: 2005704
Task: 31028
Change-Id: Ia319e8a7b4da195cb4bc861c51025a41adc43bb3
This updates our sphinx extension to show abandoned deliverables
as EOL, in a separate section at the bottom of the independent
deliverables page. It adds an 'EOL' mention to such deliverables
on team pages.
Change-Id: I56b9fbad9314c523e2f18765371746d21a71ed88
Introduce an 'abandoned' release model for cycle-independent
deliverables. It should only be applied to deliverables in the
_independent directory. No new release should be accepted for
deliverables with this release-model.
Change-Id: I65c163888c37f7a7f77273abf3ca0633923a0fe2
Shamelessly steal^Wcopy some of the code from interactive-release so
that after validating the release we list the changes that will be
released. This gives us the ability to decide that the release
contains no functional changes and elect to not create that release.
NOTE: I chose not to use interactive-release as it seems not to
correctly handle first releases in a series (because it doesn't load all
release history. It also doesn't use some of the new features (like
series_status). Adding --interactive to new-release gets us a long way
to deprecating interactive-release but we aren't quire there yet.
Change-Id: I25bbb4d7df9ae618500dd37f4b0cbc32c0bbd153
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