Commit Graph

221 Commits

Author SHA1 Message Date
Dr. Jens Harbott 97127bede1 Update for Unmaintained transition
We no longer have branches in extended maintenance state, these have
been switched to Unmaintained (eom). So we need to check for the latter
state when listing branches that could be deleted since the are EOLed.

Add oslo.utils to requirements since it is now needed by the
tools/delete_stable_branch.py script.

Change-Id: Ib948befa6f2706dc5dc50009b021af3a1bb389a8
2024-03-15 08:14:24 +01:00
Előd Illés b80fd319ee Add helper script to abandon open changes
To delete stable/<series> branches first we have to abandon all open
changes otherwise gerrit does not allow to delete the branch.
This script abandons all the open patches on a given project on a
specific branch.

Change-Id: I431fb305f998608889510f8ed2914583891d2167
2024-02-24 16:30:51 +01:00
Zuul 77a2f385ce Merge "tools: Print UTC time of branch deletion" 2024-02-19 13:47:35 +00:00
Elod Illes 706f4cd693 tools: Print UTC time of branch deletion
Could be useful when debugging Zuul / gerrit issues.

Change-Id: I7ea3e13bcc4372ac6018d177c9195e7b6a999199
2024-02-12 16:28:14 +01:00
Előd Illés 97e76562e0 Add list_eom_stale_branches.sh
This is based on the list_eol_stale_branches.sh script to make it
possible to delete stable/<series> branches where there are
<series>-eom tag already.

Change-Id: Iaaa9702c5b304152492ed2afc56ac07fb9c9fb98
2024-02-12 13:19:00 +00:00
Előd Illés 4a5c70564b Add EOM tag option to transition_series.sh
With the new TC resolution the community replaces Extended Maintenance
with Unmaintained status [1].
This patch introduces the new <series>-eom tag option in the
transition_series.sh script. The tag applies at the tip of the given
stable/<series> branch and the new unmaintained/<series> branch can be
cut from that tag.

[1] https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branches.html

Change-Id: Ia7064e36a2d92ef02f60b7371ebf3e4772abcc80
2024-01-11 16:56:57 +01:00
Zuul 784e580ad1 Merge "fix tooling to retrieve unbranched deliverables based release id" 2023-11-30 09:21:23 +00:00
Zuul 05d93632bb Merge "Fix approval check for distributed leadership type" 2023-11-30 09:15:34 +00:00
Előd Illés 1f357b54e3 Fix approval check for distributed leadership type
Teams with distributed leadership type have release liaisons listed
in governance repository's projects.yaml file instead of a single PTL.
This was introduced in the check_approval.py script, but it did not
work (though we did not realise this as usually releases repository's
release_liaisons.yaml also contains the release liaisons). This patch
fixes the check for distributed leadership type.

Change-Id: I93fbf2be0f0da85dedfe9b9f8d5876ca5b9e4b2e
2023-11-28 19:17:53 +01:00
Hervé Beraud fedd53c93a fix tooling to retrieve unbranched deliverables based release id
list unbranched deliverables is not designed to work with new release
id.

These changes add a command to allow to retrieve series id from a shell
script by passing the name of the series.

This new command is called by the list unbranched deliverables to check
if the corresponding stable branch exists (based on the release id).

Change-Id: I102b90c5221e57dd5697e2e81aa7edb8615ce445
2023-11-27 14:53:56 +01:00
Thierry Carrez ef806a0d71 Ignore ironic deliverables in ACL checks
Ironic team has several exception rules in their deliverables ACLs, in
order to be able to tag bugfixes releases amongst other things. This
change adds the Ironic team to the exception list (and removes the
Infrastructure team exception since they are no longer listed in the
governance file).

Change-Id: I33e3ecf66c66faac3e65fc8d07bdf2a6cdc022ac
2023-10-30 14:38:19 +01:00
Tony Breeds 318fcbde22 Update list_weeks to use the release yamlutils
It's a little more verbose but this is essentially the same as running
format-yaml over the generated file.  While this isn't "needed" it
isn't a functional change and makes it easier to write a tool for the
elections repo to generate changes like:
  https://review.opendev.org/q/I954afb4aad4286a8a6641ef8800541a8822a38f2

Change-Id: Iae5a79e362ea30396c70708a48005b44ec67fd62
2023-07-04 21:24:28 +10:00
Előd Illés aec6033f9c Fix announce mail with using importlib for metadata
Some package's README.rst causes metadata parsing to fail and thus
the announce job to fail. This patch looks directly for the 'name'
in metadata to avoid such failure.

Change-Id: I5dbe6bcd68bd927f28ea167f791aefea7c229a99
2023-06-02 16:25:13 +02:00
Előd Illés 431ce7005f Fix package description in announce mail
Originally 'python setup.py --description' was used, and we replaced
it to the 'description' field of importlib's metadata, but that is
actually the long description ('python setup.py --long-description').
To get the previously used 'description', the 'summary' field have to
be used.

Change-Id: I6120255dcbd9ed16c6d4fabb85f6aaad12ab01b5
2023-06-01 17:21:10 +02:00
Zuul 67b614695e Merge "Fix tools/announce by using importlib.metadata instead of setuptools" 2023-06-01 14:46:17 +00:00
Hervé Beraud 2b46589cc3 Fix tools/announce by using importlib.metadata instead of setuptools
With release of new setuptools running setup.py started
returining extra line. Eventually, running setup.py as a script is not
considered as good practice and we should not rely on it's output much.
Instead, we can leverage importlib.metadata as it should be more
reliable in long run.

Also it allow us to remove our previous workaround:
https://review.opendev.org/c/openstack/releases/+/879065

Change-Id: I52714ae92458efc0628091762cb77cf3ddb058f9
2023-05-22 10:22:09 +02:00
Előd Illés d92d989112 Fix open change list format
With latest gerrit the open changes list format has changed:
'commitMessage' title is replaced to 'subject'. Also the ordering of
the fields is replaced. With this patch we get back the originally
used formatting: '<link_to_change> -- <commit_message_title>'

Change-Id: I84e23db4ca79956b37bf4864b08f840e0d653a42
2023-04-11 16:43:44 +02:00
Előd Illés 00b2b84c48 Add workaround for announce mail script
Somewhere between today and March 23rd, 2023, pbr started to print a
log.info line when we try to fetch a package's name from setup.py, e.g:

$ python3 setup.py --name 2>/dev/null
[pbr] Generating ChangeLog
openstack_releases

A workaround is now added to our announce script to avoid garbled
announce mails [1].

[1] https://lists.openstack.org/pipermail/release-announce/2023-March/014246.html

Change-Id: I6233bb8d12a12efd3cb02abd29d8d43d7fd91da2
2023-03-30 19:25:00 +02:00
Előd Illés f1e6c1dc3c Fix list_rc_updates.sh for new branch naming
With the new release identification / naming schema [1] (like:
2023.1 Antelope) new stable branch naming was introduced (like:
stable/2023.1). list_rc_updates.sh script was not updated to this
new branch naming.

[1] https://governance.openstack.org/tc/reference/release-naming.html

Change-Id: If7027d462324d705e18c4a579316175a700e0548
2023-03-16 14:54:44 +01:00
Hervé Beraud 92684446d5 Allow to pass release ID to generate correct releasenotes links
Change-Id: Idd42a387c35a34dba5da977027d21749a7884f88
2023-03-09 11:58:27 +01:00
Előd Illés 2483ee6b7d Allow delete branch if eol tag is not at HEAD
In some cases [1] <series>-eol tag exists but it is not on the last
patch of a branch and we still need to delete them. Originally the
script skips these cases and doesn't allow to delete the branch. This
patch makes it possible to delete the branch anyway (only when the tag
exists!).

[1] for example when:
    * patches were merged after EOL tagging
    * branch was accidently recreated with new patches

Change-Id: If9491ddb292e2eebcc4c713140ce02c2d89c80a3
2023-01-25 20:43:30 +01:00
Előd Illés c73a4dd0d7 EOL branch delete script speed up
The script originally clones every repository and branch, which takes
long time. This patch queries GITEA instead whether the branch exists
there and only clones a repository if it is necessary.

Change-Id: I0e164e15a5157f6e6a42ef7ca154f207308641b7
2023-01-25 20:25:04 +01:00
Előd Illés 1502a9d517 Add progress info printouts to list_eol_stale_branches.sh
As the script runs it takes time to process every branches. This patch
changes the script to show the current repository being processed.
Also fixes variable name.

Change-Id: Ifde9aa5bec30e18a12a9c5107888943a4af3e271
2023-01-23 14:41:08 +01:00
Előd Illés 0356a73c74 Remove tag argument usage from helper scripts
The TC tags framework is discontinued [1], so all references to TC tags
will be invalidated once TC passes the change.

This patch removes the use of '--tag stable:follows-policy' from helper
scripts.

[1] http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027214.html

Change-Id: I30645f45c270f436605ef5024557e341a6851dce
2022-03-16 20:27:22 +01:00
Előd Illés 20ece035ab Do not add reviewers when bulk pushing changes
There are multiple problems with it:
* the --reviewers options works differently, as it should be added only
  once and then listed the emails
* in case of dummy contacts or not registered contacts the git-review
  command fails

Since we have already a script [1] to add reviewers to *every* open
patch, it is easier to run that *after* we finished the bulk uploading
of patches.

[1] tools/add_reviewers.sh

Change-Id: I2942033134adb30db0cd7e955f7bf8aefbbb3c5b
2022-02-28 21:39:35 +01:00
Előd Illés 4f103be7f4 Add question before pushing a patch with bulk_review.sh
When running this bulk command it is always good to double check what
we are pushing to gerrit. This patch shows the commit message with
changed files list with 'git show --stat' command and then waits for an
Enter. This also makes it more visible if a git push has failed.

Note: when aborting the script the branches will remain in our local
git repository and that needs to be cleaned if we want to run the
script again. Though this is also valid if we don't cancel the script.

Change-Id: If23202be15493d2ac9bccd3e2d1af04395b18a23
2022-02-28 21:33:06 +01:00
Zuul 0e01c2b149 Merge "List cycle's releases with process_auto_release" 2021-11-12 15:18:45 +00:00
Hervé Beraud 3dfdc3e59b Allow to check release approval for DPL teams
These teams are PTL-less and not necessary define their
release liaison in openstack/release/data/release_liaison.yaml.

The problem is that their release liaison approval is not
necessarily detected.

These changes allow to consider these release liaisons folks.

Furthermore, patch Id0d6eeaf66394806374781d1cf26c087a6e90f87,
from the similar script in project-config repository, also applied
here in this script to avoid exception in case of DPL teams.

Change-Id: Ieaf1eafc6a8e3ce443d73876e525f738e51dea67
2021-11-05 16:08:19 +01:00
Hervé Beraud 6d7482db5b List cycle's releases with process_auto_release
Without knowing which releases have been made within the given
series either we shoots in dark in choising the kind of release
(bugfix, feature, major, etc...) or we need to check manually
what are the existing versions. That's time consuming.

These changes simply display the current versions available in
the given series.

Change-Id: Idb160198d52d3bc6b0fa00095b143b19a1f130eb
2021-09-17 11:56:37 +02:00
Előd Illés 632b30df6d Fix list_eol_stale_branches.sh to list only stale branches
clone_repo script does not fail if the branch does not exist, but
checks out the master branch [1], so we have to make sure the required
branch exists.

This patch also adds a check that there were no more patches merged
after the given branch was tagged EOL.

[1] https://opendev.org/openstack/releases/src/branch/master/tools/clone_repo.sh#L187

Change-Id: Ia1ededfc3cebbae807719750dc5e2d5949ce9a21
2021-05-03 21:51:51 +02:00
Hervé Beraud 030a2200d2 Allow to change the used branch
The branch to use in process_auto_release is determined by the
branch linked to a series's status, however, at some point during
a series projects are branched and the status isn't yet updated
so used branch refer to master, and so, to the next series.

During the final-rc delta of changes between RC1 and RC2 is
retrieved from master, which is wrong.

These changes allow to choose another branch if needed.

The default used branch will remain the series retrieved
by status.

Change-Id: Iff8df80aa6f3ba67c04e0674d7c72474f3a4e73a
2021-04-26 14:21:01 +02:00
Hervé Beraud 57d91b0b13 Ignore trailing projects from RC1
Some traiing projects follow the cycle-with-rc model however our doc
and our tools doesn't differentiate them during RC1. These project
doesn't have to be released during RC1. These changes adapt our process
accordingly.

Change-Id: I44040bc040f19a75c468d385395323fe0a1f459a
2021-03-26 12:05:21 +01:00
Zuul 06778aa645 Merge "Add delete option to list_eol_stale_branches.sh" 2021-03-08 11:25:40 +00:00
Zuul c9e96c9c20 Merge "Adding a tool to catch projects that missed branching" 2021-03-05 14:20:39 +00:00
Előd Illés 6a8941429f Add delete option to list_eol_stale_branches.sh
This patch adds a question whether to delete a stale eol branch if it
does not contain open patches.
The deletion is done via Gerrit API, which requires 'delete reference'
access category for the user who is running this script.

Change-Id: Iea33c2bd4bd20dd0f92fd9a7e12008d841176974
2021-03-04 17:12:43 +01:00
Hervé Beraud c42fa88865 Adding a tool to catch projects that missed branching
This tool will be used in doc addition around the branching period
to ensure that we don't miss to create stable branches for project.

Also this tooling should be used around each trailing deadline to ensure
to not forget a trailing projects. Trailing projects are those who can
easily meet the conditions that lead to forget to branch them.

Adding usage of this tooling in our process to ensure to check that
point once a time at each new series.

Change-Id: I2a8bd25ecfe5bb1bde5af16b08f897a5bdc11cb7
2021-03-03 13:51:12 +01:00
Előd Illés b293ca4bcb Optional list of changes in commit message for auto release
When generating release patches with process_auto_releases.sh it could
be useful to have the list of changes in the commit message of the
release patch. This patch adds an extra question for that.

Change-Id: I8f26fb5655ef1cd280b243cadbb7b49d596e7d51
2021-02-25 11:53:52 +01:00
Hervé Beraud dfb43b49ef Check if patches remain opened on stale branches
Gerrit won't allow deletion of a branch with open reviews [1]. These changes
allow us to early detect that.

[1] http://lists.openstack.org/pipermail/openstack-discuss/2021-January/020034.html

Change-Id: I603b1ac864b5b34db7466007b1bb78a0887f87b5
2021-01-27 18:05:22 +01:00
Hervé Beraud 003eb35717 Adding a tool to track project who need to drop eol branches
Since transition from the EOL model to the EM model eol branches
are no longer removed and this step is no longer in the release team
process.

Keep stale branches can be an issue in some situation especially with
zuul and our gates. To avoid this situation the release team propose
to reintroduce regular checks to ensure that we remove stale branches
that have been tagged eol previously.

As discussed during our previous meetings soon it will be possible to design
a new job and to trigger it to remove eol branches automatically.
This will possible when the infra would have been updated and when all
the needed pieces will be in place.

Change-Id: I53aeb3211bb3251a3278472a514a39afe825cdd2
2020-11-12 10:57:39 +00:00
Hervé Beraud a8ab91eebc Adding a new tools to search topic on the ML
By default it will research for topics related to the release team but
pattern can be overriden to looking for all kind of topics (c.f the
related doc).

Usages
------

The following example will search for all emails sent openstack-discuss
who match release topics from the creation of the mailing list to the
current day:

```
$ tools/search_emails.py
```

In the following example we search for release countdown emails sent
between May 2020 and today:

```
tools/search_emails.py --topic ".?\[release\] Release countdown.*" --starting-date 2020-5-1
Looking for emails between 2020 May and 2020 September and sent by
Analyzing May 2020: http://lists.openstack.org/pipermail/openstack-discuss/2020-May
Analyzing June 2020: http://lists.openstack.org/pipermail/openstack-discuss/2020-June
Analyzing July 2020: http://lists.openstack.org/pipermail/openstack-discuss/2020-July
Analyzing August 2020: http://lists.openstack.org/pipermail/openstack-discuss/2020-August
Analyzing September 2020: http://lists.openstack.org/pipermail/openstack-discuss/2020-September
15 result(s) have been found
2020-May:
        - [release] Release countdown for week R-1, May 4 - 8 - Sean McGinnis
        http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014577.html
        - [release] Release countdown for week R-0, May 11 - 15 - Sean McGinnis
        http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014780.html
        - [release] Release countdown for week R-20, May 25 - 29 - Sean McGinnis
        http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014999.html
2020-June:
        - [release] Release countdown for week R-17, Jun 15 - Jun 19 - Sean McGinnis
        http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015415.html
        - [release] Release countdown for week R-16, Jun 22 - Jun 26 - Sean McGinnis
        http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015541.html
2020-July:
        - [release] Release countdown for week R-13  July 13 - July 17 - Sean McGinnis
        http://lists.openstack.org/pipermail/openstack-discuss/2020-July/015878.html
        - [release] Release countdown for week R-12  July 20 - July 24 - Sean McGinnis
        http://lists.openstack.org/pipermail/openstack-discuss/2020-July/016056.html
2020-August:
        - [release] Release countdown for week R-10  August 3 - 7 - Sean McGinnis
        http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016243.html
        - [release] Release countdown for week R-8 Aug 17 - 21 - Sean McGinnis
        http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016534.html
        - [release] Release countdown for week R-7 Aug 24 - 28 - Sean McGinnis
        http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016709.html
        - [release] Release countdown for week R-6 Aug 31 - Sept 4 - Sean McGinnis
        http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016894.html
2020-September:
        - [release] Release countdown for week R-5 Sept 7 - 11 - Sean McGinnis
        http://lists.openstack.org/pipermail/openstack-discuss/2020-September/017079.html
        - [release] Release countdown for week R-4 Sept 14 - 18 - Sean McGinnis
        http://lists.openstack.org/pipermail/openstack-discuss/2020-September/017210.html
        - [release] Release countdown for week R-3 Sept 21 - 25 - Sean McGinnis
        http://lists.openstack.org/pipermail/openstack-discuss/2020-September/017399.html
        - [release] Release countdown for week R-2 Sept 28 - Oct 2 - Sean McGinnis
        http://lists.openstack.org/pipermail/openstack-discuss/2020-September/017616.html
```

Change-Id: Ib1fe5f74b408ac489b12c4ef003860ce7aee1532
2020-10-02 15:57:38 +02:00
Sean McGinnis 355cd7debd
Add script to semi-automate bulk releases
The release team has a few cases now where we need to propose release
patches for a large set of deliverables. Due to differences in semver
choice based on actually merged commits, along with other decisions that
need to be made while doing these, this process can't be completely
automated. But this adds a script that will automate the majority of the
process to simplify it as much as possible.

Change-Id: I6ec9fa77baab58df93bdadc0ac3c3fa5d3e18804
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
2020-09-11 14:48:55 -05:00
Sean McGinnis 493b7bf33a
Update to latest hacking for pep8 checks
This updates the version of hacking we are using for our linting and
addresses various issues that the latest version flags.

Change-Id: I95ed73411e96451bc447e1b5858b0466fb8f10a9
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
2020-07-27 16:33:03 -05:00
Sean McGinnis 08cd1fb33c
Switch to PyYaml safe_load
The load() call from PyYaml is considered a higher security risk in that
it uses the FullLoader. safe_loade() is considered more safe by using
the SafeLoader instead.

Since the 5.1 release of PyYaml added warning output when using load(),
this switches over to safe_load() to avoid the unnecessary noise.

Change-Id: I1949deed094822d2c2c56659eadb1fc5ea6a59e5
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
2020-07-27 16:18:19 -05:00
Zuul ca7d97f823 Merge "Allow list_unreleased_changes to format results at json & yaml formats" 2020-07-10 16:05:02 +00:00
Hervé Beraud 4912f7d5d0 Allow list_unreleased_changes to format results at json & yaml formats
Rewrite list_unreleased_changes as python format and add new features.

By default it will behave as the previous version of this command (the
shell script).

Few new feature have been added in these changes to allow us to more
easily handle outputs in scripts.

Features added:
- allow user to retrieve results in json format
- allow user to retrieve results in yaml format
- allow user to ignore project not yet released

The shell script entry-point (tools) is still there but it will call
the python command in a venv instead of directly implement features.

Also the python version allow us to more surround this tools with unit tests.

Change-Id: Iaf86ecb1589c40102acb621b23ea12d71ed453bb
2020-07-07 19:07:25 +02:00
Hervé Beraud 339af5321a Fix tox command in tool help
Also prefer to use retrive command name dynamically.

Change-Id: Iffe7fe3216256ddb52001e4fcfa49cc3ea82d6e8
2020-07-07 17:39:24 +02:00
Sean McGinnis 62c2fc4317
Use updated git cache dir default path
Change-Id: I7c3ed1e08c7ef1a62845df0d9c5b22f400d8d90b
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
2020-05-13 06:13:07 -05:00
Sean McGinnis 27d4f7db98 Update add_reviewers to add to all open reviews
This updates the script to not require a specific topic to make it
easier to automate a job that periodically makes sure all open reviews
have had the PTL and liaison added.

Also refactored the adding of teams because bash array handling can be a
bit wonky sometimes and not always append values. This makes sure no
teams are skipped.

This is slightly less optimized for large reviews like the final series
release since it loops through teams based on the deliverable files. As
a slight optimization, it will skip a team if it was the same team as
the last deliverable file. It just might be possible that the same team
will be processed multiple times if their deliverable files are not in
alphabetical order, but there is no harm in that other than taking
slightly longer to complete.

Change-Id: I9a9194ea276aa0120aef21a321f48a93419fb848
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
2020-05-09 07:15:06 -05:00
Hervé Beraud ae48bf825b Display more help to the new-release wrapper
If we miss something with this command we need to get the
python script's help to get how to use this tools, these changes
add the command to execute through the wrapper to get this help.

Change-Id: I1e9fceece6fee40722e21e49ca5689faacefdf93
2020-05-05 22:37:17 +02:00
Thierry Carrez d40c4ca491 Rely on Zuul to provide project name in announces
If we run in CI, rather than prioritizing using 'python setup.py --name'
as the project name to be used in release announcements, use the
repository name as provided by Zuul.

This should fix the issue reported in:
http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014359.html

Change-Id: Ia0026356676561a6b3a55ab05db5ed7a58b646b6
2020-04-24 12:41:09 +02:00