602 Commits

Author SHA1 Message Date
Hervé Beraud
14484c5055 Fix propose-final-releases command to use release-id
With the new release identification / naming schema [1] (like:
2023.1 Antelope) new stable branch naming was introduced (like:
stable/2023.1). This was not handled in the propose-final-releases command as
it still uses the release name. This patch fixes this by reading the
'release-id' field from series_status.yaml and if present then uses it
as stable/<release-id> for the branch creation.

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

Change-Id: Ie8ba3e9bfa01148e93f5920050703e998248db11
2023-03-20 11:05:56 +01:00
Zuul
54c1126a53 Merge "Fix for independent projects" 2023-03-14 09:27:28 +00:00
Hervé Beraud
759732ebc1 Fix list-deliverables command to use release-id
With the new release identification / naming schema [1] (like:
2023.1 Antelope) new stable branch naming was introduced (like:
stable/2023.1). This was not handled in the list-deliverables command as it
still uses the release name. This patch fixes this by reading the
'release-id' field from series_status.yaml and if present then uses it
as stable/<release-id> for the branch creation.

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

Change-Id: Id6a03024fa2268ba233189abfe48556d3530daef
2023-03-06 10:54:11 +01:00
Riccardo Pittau
bb2d6399cd Fix for independent projects
Independent projects do not have "stable" branches, so the
new_release script will fail.
Set version to master and change it accordingly only if it's not
and independent project.

Change-Id: I9ba7f251d64e2bfca5c262acf9b20dc3da23fc87
2023-03-03 16:48:11 +01:00
Zuul
7b8319b5b9 Merge "Fix new-release command to use release-id" 2023-03-03 14:56:09 +00:00
Előd Illés
32c9bc69eb Fix validator for tagless deliverables
With the new release identification / naming schema [1] (like:
2023.1 Antelope) new stable branch naming was introduced (like:
stable/2023.1). This was not accepted in the validator command.
Previously the validator was fixed for 'std' and 'std-with-versions'
branching typed deliverables, but missed the 'tagless' deliverables
case. This patch fixes this by accepting the new branch naming style,
stable/<release-id>, for tagless deliverables, too.

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

Change-Id: I6ba51454213e095e6b76e0813dab3ce44b1457ba
2023-02-27 17:16:25 +01:00
Előd Illés
9e0196311a Fix new-release command to use release-id
With the new release identification / naming schema [1] (like:
2023.1 Antelope) new stable branch naming was introduced (like:
stable/2023.1). This was not handled in the new-release command as it
still uses the release name. This patch fixes this by reading the
'release-id' field from series_status.yaml and if present then uses it
as stable/<release-id> for the branch creation.

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

Change-Id: Ic9888b74b398d14f2a1dc5b6d30bca5f23493b5b
2023-02-27 13:11:34 +01:00
Előd Illés
3f96e774ce propose-library-branches command with release_id
With the new release identification / naming schema [1] (like:
2023.1 Antelope) new stable branch naming was introduced (like:
stable/2023.1). This was not handled in the propose-library-branches
command as it still used the release name. This patch fixes this by
reading the 'release-id' field from series_status.yaml and if
present then uses it as stable/<release-id> for the branch creation.

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

Change-Id: Ie87862669fb965729e23a9374c34b1ba2e71b445
2023-02-20 18:18:04 +01:00
Előd Illés
27c4dcced7 Fix validator for std-with-versions
For projects that has branch type 'std-with-versions' (like ironic,
because they cut bugfix/<MAJOR>.<MINOR> bugfix branches) the new stable
branch name style (like stable/2023.1) does not pass validator. This
patch extends the validator to accept these branch names, too.

Change-Id: If597684b1a4ea741707ee786e8e01e9e8f3d2cb4
2023-01-20 11:40:59 +01:00
Hervé Beraud
032f60e961 Fix stable branch naming validation
This fix aim to solve issues with the new naming convention related to
SLURP releases.

Without that our validation will fail to validate stable branches named
like `stable/2023.1`.

Change-Id: Ic45d4a13f63846e5b60bde800492da7c851addf8
2022-12-02 14:33:14 +01:00
Előd Illés
671c4b7a09 Update _CLOSED_SERIES set with Wallaby
Validation is not needed for a series as soon as it reaches the
Extended Maintenance state as there won't be any releases from such
branches. This patch updates the set of closed series to avoid
unnecessary validation.

Change-Id: I0f093865bab190273421d966c755434d0369e0a0
2022-10-21 20:01:34 +02:00
Radosław Piliszek
52f52d8340 Fix new-release in interactive mode (-i)
Stop overwriting the target sha value.

Change-Id: Ie8b39bd848c659ac8834b063d5b1e7bb9da2a1e3
2022-10-10 18:18:26 +00:00
Előd Illés
e83bb1f69a Uncap jsonschema
With the latest upper constraints updating generated patch [1] the
openstack-tox-docs job started to fail, due to conflict:

ERROR: Cannot install jsonschema<4.0.0 and >=3.2.0 because these
package versions have conflicting dependencies.

The conflict is caused by:
    The user requested jsonschema<4.0.0 and >=3.2.0
    The user requested (constraint) jsonschema===4.7.2

This is because we have jsonschema<4.0.0 in our requirements.txt.
By uncapping the constraint the docs job is passing.

Date validation needed to be updated as well, because a deprecated
usage of validator extending method was used in the code, which was
removed [2] from jsonschema with the 4.0.0 release. This patch replaces
that with adding a TYPE_CHECKER instead.

With the new jsonschema constraint openstack-tox-py36 job does not pass
anymore, but py36 is dropped from zed anyway. That job is pulled in by
an old job template, which needs to be replaced to the new zed job
templates, too.

[1] I89576353371aa87d181610eb6242cbe961487af6
[2] d9f6384060

Closes-Bug: #1982757
Change-Id: Ida6310dd822e587ce9c424a228fdff5192ba0476
2022-07-26 12:24:11 +02:00
Előd Illés
b4e04e95f7 Update _CLOSED_SERIES set
Validation is not needed for a series as soon as it reaches the
Extended Maintenance state. This patch updates the set of closed series
to avoid unnecessary validation. Together with Victoria, now this patch
adds older series, too, that were missed at their transition time.

Change-Id: I3f2b98540757a2370a923d71f8a38e15fbe35985
2022-07-08 15:54:07 +02:00
songwenping
0ffbc53211 Remove six
We don't need this dependency anymore.

Change-Id: I816b9aa687b90299326085b642c992e42c11c029
2022-04-19 10:19:15 +08:00
Radosław Piliszek
50a5af421e Remove references to TC tags
The TC tags framework is discontinued [1], so all references to
TC tags will be invalidated once TC passes the change.
This patch removes these references to avoid breaking the releases
repo.

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

Change-Id: Idf5cddc7d1a535e1a9bcc2c2922cf23c3a8d539b
2022-03-16 20:30:07 +01:00
Előd Illés
909d616cf4 Remove stable:follows-policy tag banner
TC tags framework is discontinued [1], so the banner is not needed
anymore in our list-changes command as it won't be triggered.

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

Change-Id: Iff26be4cc1701bf31a1030c10fce0b2486da3e85
2022-03-16 20:30:07 +01:00
Hervé Beraud
5d5c666e9f Fix validation when tags are missing and a branch is requested
For further details see
https://review.opendev.org/c/openstack/releases/+/818445

Change-Id: I291ee6e28cc6dcc901295336dd1251b9d28dc0b4
2021-12-02 09:46:12 +01:00
Zuul
0e01c2b149 Merge "List cycle's releases with process_auto_release" 2021-11-12 15:18:45 +00:00
Hervé Beraud
59cabc808c Allow to add reviewers for DPL teams
These teams are PTL-less and not necessary define their
release liaison openstack/release/data/release_liaison.yaml.

The problem is that their official reviewers arn't necessarly
detected.

These changes allow to consider these release liaisons folks.

Change-Id: I29295dddb2619043a43957e5e2c2f64d0787784b
2021-11-08 17:28:43 +00: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
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
Hervé Beraud
60f7b61406 fix nits
Change-Id: I7e543ad3265f81f51bd7edbcd1e780991b849c98
2021-03-05 17:32:09 +01:00
Zuul
c9e96c9c20 Merge "Adding a tool to catch projects that missed branching" 2021-03-05 14:20:39 +00: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
Hervé Beraud
80652b5232 Ensure that we can build sdist from requested tags
Adding validation check to ensure that we are able to build sdist from
the latest tag.

This will allow us to detect sooner when we will try to add a tag to a branch
which is older than another tag already on that branch/in that branch's history

Indeed we recently experienced similar issue [1] with os-collect-config and
tripleo-ipsec where projects hadn't been branched for ussuri [2] and where
we tried to create a new ussuri release [3] on the same hash that an
existing wallaby tag.

Projects have been branched [3] after tags creation [2].

[1] http://lists.openstack.org/pipermail/openstack-discuss/2021-January/020112.html
[2] 688914aa29
[3] ihttps://review.opendev.org/c/openstack/releases/+/772047

Change-Id: Ie2d055f171418e2d35db697dfb1aa17cd449bea9
2021-02-17 17:17:25 +01:00
Hervé Beraud
8d61d2482b Allow to tag projects as "last" on EM branches
For testing for Extended Maintenance branches with branchless
Tempest and Tempest plugins, we need to release the new tag
for Tempest and its plugins as last compatible version for that
Extended Maintenance branches.

This commits adds the documentation and validation machinery changes about
that tag $series-last which will be used for branchless testing tooling.

Change-Id: I799e8e637a54a46fd7ca74dd568ea2c7506fa32d
Depends-On: https://review.opendev.org/c/openstack/project-team-guide/+/769821
2021-01-12 11:56:50 +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
Zuul
e8cd9543de Merge "add tooling to list em series from data" 2020-11-05 10:35:46 +00:00
Hervé Beraud
d8aba0991d add tooling to list em series from data
Change-Id: I114f08c0c1c38a31f34d798562dd530910bcd3d5
2020-11-04 16:53:14 +01:00
Zuul
543785f218 Merge "init-series: Skip unrelease comment for trailing" 2020-10-26 13:04:26 +00:00
Sean McGinnis
0c265869aa
init-series: Skip unrelease comment for trailing
Cycle trailing deliverables are often not released by the time we
initialize the next series. We add a comment to deliverable files during
their creation to note if they were not released in the last cycle to
help highlight orphaned deliverables. This can be misleading for cycle
trailing deliverables, since usually they do end up being released, but
after we've created the file and included the comment.

To make this comment more useful, this removes its inclusion for
trailing projects.

Change-Id: I010dadc2ca9026248e7f9dfc89d257afdf97be72
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
2020-10-19 10:36:42 -05:00
Hervé Beraud
9c4f3c4303 Allow to consume projects without the openstack prefix
Change-Id: Idbf382d83a9af05b17b8def7154c7390b6a7a5b0
2020-10-06 11:46:09 +02:00
Doug Hellmann
6fe3672660
add reno semver-next to the list-changes output
Use `reno semver-next` to check the proposed version against the types
of changes described in the release notes.

Change-Id: I9ac52ff524440670366ebeceb11dc04a446e876c
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
2020-09-03 08:34:49 -04:00
Riccardo Pittau
e53454c494 Add intermediate-branch arg to new-release script
This allows the projects with a cycle-with-intermediary release model
to be able to automatically generate the yaml file with the correct
new branch.

Change-Id: I003e5d3d39cbb8961822b3fd2a384bf3c9f66f5e
2020-08-12 17:16:26 +02:00
Zuul
92545dacb0 Merge "Update to latest hacking for pep8 checks" 2020-08-03 14:01:38 +00: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
Hervé Beraud
d63b38783a Fix a bug on list_unreleased_changes during tag retrieving
Indeed `gitutils.gitutils.stable_branch_exists` is waiting for a branch
name not prefixed with `stable/`. This was not an issue with the
previous shell version. These changes fix that.

Without these changes the master branch will be analyzed and stable
branches will be ignored.

Change-Id: I61542508e8566eb797b0e304a6914d25e3b07e14
2020-07-27 22:04:08 +02:00
Hervé Beraud
85d8c3eb31 Add some whitespaces on helps to fix rendering.
Change-Id: I444fc8f48d5d17437814b7a31f7c5b90775e3543
2020-07-27 11:23:02 +02:00
Ben Nemec
d0bd6e76f3 Add newline between projects in std output format
Without this it is very difficult to visually distinguish between
the project outputs.

Change-Id: I452aa5500bda1bf607ba11baa92be3377945a4ab
2020-07-24 19:12:45 +02:00
Hervé Beraud
9e0b82d820 Fix list_unreleased_changes when repo doesn't exist or haven't been released
Indeed during my previous implementation of this script, I missed to handle
the cases where repo is not found or has not yet been released when users
ask for a standard output. For yaml and json is not an issue as we dump
raw dict at the asked format (json or yaml).

These changes fix that.

Also to stay closer of the previous implementation of this tools (the
shell version), these changes add:
- colored outputs
- compared revisions (even when no diff are found,
  like in the previous shell version).

Change-Id: I74f0f8c7071fbf2c8272fc002f28b793ff8e672d
2020-07-22 17:36:43 +02:00
Ben Nemec
1a08f4b439 Fix output format default in list_unreleased_changes
"standard" is not one of the valid values and it results in the
command erroring because no output is returned. The correct default
for this opt seems to be "std".

Change-Id: I7df3feb98877b2a846f7239fb741ae84e35b59d5
2020-07-21 15:36: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
Sean McGinnis
d593479b0b
Test bugfix branching with release-test
This does a new release with release-test to see if everything is
covered to allow branches to have a bugfix/* prefix.

Change-Id: I7869cf412524d7352249f02f7449b2fddf401d2c
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
2020-06-29 15:40:12 -05:00
Thierry Carrez
8a9f755cb9 Trailing is a deliverable type, not a release model
Cycle-trailing deliverables are regular cycle-following deliverables,
using RCs or not not using RCs -- they just have a different deadline.

Rather than using a release model, those deadline variants are better
described using deliverable types, in much the same way 'library'
deliverables have a specific deadline too.

This simplifies the list of models significantly, and allows to have
proposer validation of trailing deliverables that use RCs or not use
RCs.

For compatibility in old branches, setting 'cycle-trailing' is still
supported, it will just overload the type to 'trailing' if specified.

Change-Id: Ifce88ef3e5dd406f45f25214699f16e736ad5377
2020-06-16 16:18:30 +02:00
Thierry Carrez
50fbc33845 propose-library-branches: remove unused --all option
The --all option was copypasted from propose-final-releases but
ignored afterwards.

Change-Id: I1023c659506b12d833d856f16b604c8ba24c11f5
2020-06-15 13:49:52 +02:00
Sean McGinnis
804e560832
Add std-with-versions stable-branch-type
This adds a new std-with-versions branch type. This is used to control
validation logic when branching to allow the Ironic team to create
intermediary stable branches based on major.minor version numbers in
addition to our normal expected stable/$series branches.

https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/new-release-model.html

Change-Id: Ic482c77a2c177162ffe37643a455ac1724a658b3
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
2020-06-02 14:34:32 -05:00
Zuul
4b9898b2bd Merge "Add retries to sending emails" 2020-05-25 17:23:34 +00:00
Zuul
67228ca836 Merge "[fix] list-deliverables when branch type is undefined" 2020-05-20 11:54:54 +00:00
Hervé Beraud
6f599fe5be [fix] list-deliverables when branch type is undefined
These changes fix the `list-deliverables --no-stable-branch` command when
`stable-branch-type` is `none`.

Previously projects with `stable-branch-type: none` was returned in
results.

Project with this type of stable branch should be ignored when we
looking for projects with no stable branche (`no-stable-branch`).

Change-Id: I05c0e7e153e9ddbe5bc3632de9bfdde411ab580d
2020-05-18 13:24:53 +02:00