There is no real reason we should be using some of the
terms we do, they're outdated, and we're behind other
open-source projects in this respect. Let's switch to
using more inclusive terms in all possible places.
Updated playbooks and related code accordingly.
Change-Id: Ia471193921660aa5f2152ab63eaf570bee3ebcd0
Depends-on: https://review.opendev.org/c/openstack/requirements/+/917786
Patch I55ee87cdb9ee712c334c798a1c2a7ba745e5870e extended the
make_branch.sh script to not (re)create stable/* or unmaintained/*
branches in case a <series>-eol tag exists. However the bash string
manipulation magic doesn't work correctly in the job, which
resulted that some stable/* branches were recreated.
This fix removes the complex magic and only relies the proved to be
functioning string manipulation.
Change-Id: I3aecdc03ec720ea756a5ba467cc6073b7b7d7941
Currently there is an error happening if a deliverable does not have the
series defined which is being transitioned to unmaintained. Check
whether the series file actually exists before trying to modify it and
exit gracefully if it doesn't.
Change-Id: I8817a95656bad0b03243a415c4d3d364e85c048c
When we cut unmaintained/<series> branch, the <series>.rst reno page
needs to be updated to use unmaintained/<series> branch instead of
stable/<series> branch, as that is deleted.
Change-Id: I811d13d4d524ae83e14acbe8e16888c7f1d91e57
This was updated in the release repo with [0] but missed to update in
this copy here.
[0] I7c3ed1e08c7ef1a62845df0d9c5b22f400d8d90b
Change-Id: If45f95cf530984240b9999f06b28c2602b03ab26
With the new TC resolution the community replaces Extended Maintenance
with Unmaintained status [1].
The make_branch.sh script needs to be extended to
- do not re-create stable/<series> branch when <series>-eom tag exists
- do not re-create unmaintained/<series> branch when <series>-eol tag
exists
[1] https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branches.html
Change-Id: I55ee87cdb9ee712c334c798a1c2a7ba745e5870e
Teams with distributed leadership type have release liaisons listed
in governance repository's projects.yaml file instead of a single PTL.
This was not handled in the check_approval.py script so far.
Fixing this by synchronizing the script with releases repository's
tool/check_approval.py script's relevant part.
Change-Id: I2433113e1168b10ba03831b30b82e46f3ec1c72f
With a recent patch a new release job error came up [1]:
when fetching the release-id from the series_status.yaml the yaml
parser resolves the new names (eg: 2023.1) as float, so we have to
convert it to string to be able to concatenate it to 'stable/' string.
[1]
File "/home/zuul/scripts/release-tools/process_release_requests.py", line 116, in get_branch
branch = "stable/" + series.get("release-id", series_name)
TypeError: can only concatenate str (not "float") to str
Change-Id: I4e317919292d7481b2ffd15b68473fff5b4b9aaf
In [1] we saw that releases on antelope are proposed as constraint
updates on master. This is another case where series != release-id.
Add meta:branch to the release metadata and use that when updating
constraints
[1] https://review.opendev.org/q/I369b2140ff3203d069530dcbabffb79cd29d859b
Change-Id: Ic4ea185d54a7e82bcb9fae3c1291a4c3bb456f22
Currently we have a, short, static list of closed releases. We
maintain this data in series_status.yaml. This change loads this
data to build CLOSED_SERIES on load.
Change-Id: I3270eb7771f892cf8b2de760c1d0966bcfc8417c
In case a branch is End of Life (marked with either $series-eol or
bugfix-<version>-eol) and was deleted before, then our script recreates
it based on the info in deliverable's yaml file.
This patch extends the script by checking if an *-eol tag exists and
in case it does then exits without creating again the already deleted
branch.
Change-Id: I1b763aa52703221d211156c060b8998282fcfc5d
In Zed cycle, TC agreed to use the unversioned job template [1]
(implemented in [2]), thus we don't need the script to generate the
patches. This removes the script and also the lines where the script is
called from, so OpenStack Bot won't propose any change regarding the
series specific job templates.
[1] https://etherpad.opendev.org/p/tc-zed-ptg#L360
[2] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/856903
Change-Id: I8c8aa9ae1fc395361fa6162983feac631608032f
From 2023.1 cycle, TC agree to make python version
template to be unversioned
- https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/856903
This commit updates the release script to update the
unversioned template from next cycle.
Change-Id: Icf03e279bf574f5ff0c0f14b53c4ef76b6098c46
A later version of ansible-lint enforces names on blocks. This is
generally a good rule; fix a few missing blocks here.
Change-Id: Ia87a0c21ec0ed1662e37cbc9e17a0df344b54e57
These were found by a later version of ansible-lint. This should have
no effect, but just fixes some inconsistent whitespace issues.
Change-Id: I7bcde4942c97cfe743e8aba74833aeb5844c8290
Pip 22.0 switched[*] its HTML parser library for one which demands
strict adherence to HTML 5, and so cannot work if told to include
our wheel indices because they lack a doctype declaration on the
first line. Add one.
[*] https://github.com/pypa/pip/issues/10825
Change-Id: Ia863e313e656e67191e1ca3aea968a7f3e4059a6
This adds a step in the launchpad interaction during a release to set
the bug task status to "Fix Released" for the series being released.
Change-Id: I9fbbed3131e2ebfd590f27c569603add15bc969d
``django_openstack_auth`` code was merged into the main horizon
repository during the queens release. This repo is already
deprecated and now we can retire it. This patch removes all
references of ``django_openstack_auth`` as mentioned in [1].
Also, this patch takes care of step 2(End project Gating)
and and step 4(Remove Project) because
step 1(Stop requirements syncing) and step3(Remove Project Content)
is already handled by If04778ccc99ea92355378d59e616d8794e36ea14
and I74b10a90fe79fc768cfb8de6f68d3cd2f4938e51 respectively.
Note: this patch doesn't drop the official-openstack-repo-jobs template
and noop-job because noop-job is needs to be defined for the check and
gate queues to merge a patch and official-openstack-repo-jobs is needed
to syncup the changed in github repo once Ib811fb321d18fc01f3786f8b3ab16b2eda558864
merged we can drop this template and noop-job.
[1] https://docs.openstack.org/project-team-guide/repository.html#retiring-a-repository
Change-Id: Ifa691c2d2e7ac8bb502c8fae7dbdcc89fa4ef825
In the normal course of script execution, clone_repo.sh routinely logs
the following error message:
error: pathspec 'xxx' did not match any file(s) known to git
This error can be safely ignored, as the script moves on to checking out
master instead. But it can be (and has been) mistakenly interpreted as
the reason why the script fails.
This change avoids logging the error message and logs a clearer
explanation instead.
Change-Id: Iaaaed7b0ea343bd81b8ad898654658545942a3d0
Use python3 when running the script to add release note page as
part of the release process.
Without that we get the following error:
```
2020-12-26 16:58:15.569890 | ubuntu-focal | + python -c 'print('\''victoria'\''.title())'
2020-12-26 16:58:15.570573 | ubuntu-focal |
/home/zuul/scripts/release-tools/add_release_note_page.sh: line 51:
python: command not found
```
c.f http://lists.openstack.org/pipermail/release-job-failures/2020-December/001499.html
Change-Id: I6a5a68570b8948692aa48f09003d26590ee621e4
Not all teams have PTLs now. Don't assume we will get PTL information as
we check for approvals on release patches.
Change-Id: Id0d6eeaf66394806374781d1cf26c087a6e90f87
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Octavia has a diskimage-builder element to install octavia-lib. When
creating an amphora image from an Octavia stable branch, the expectation
is the octavia-lib code will match the same branch (master or stable).
This patch updates the branch name and upper constraints for octavia-lib
in Octavia on stable branch creation.
This change is in line with I8eba64c886c187c8652f94735ca6153702203d17.
Depends-On: https://review.opendev.org/#/c/745506
Change-Id: I31b762f631304636bafabec9c54cd31c6c91f124
We can not speculatively test changes to the wheel build jobs while it
is project config. These jobs are in the gate for the requirements
project, which run them when bindep.txt changes.
https://review.opendev.org/731394 moved the build-wheel-mirror-base
job/playbook/role into openstack-zuul-jobs, renamed as
build-wheel-cache-* to a) distinguish the name and b) make it a little
clearer that we're building the wheels that goes on the mirror, rather
than passing through to mirroring something existing.
This updates the job names in project-config to reference these new
jobs.
Note the publishing steps are kept here along with the AFS secret.
Depends-On: https://review.opendev.org/732085
Depends-On: https://review.opendev.org/732087
Depends-On: https://review.opendev.org/732083
Depends-On: https://review.opendev.org/732084
Depends-On: https://review.opendev.org/732086
Change-Id: Iac3a906803177e8365f4cfb611800b5ccaed4a6e
It seem that pip has updated its verbose output to say "Downloading
$filename" rather than "Downloading from url $URL". We need to update
our wheel mirror processing to handle this change so that it can
properly remove any pypi hosted wheels before publishing to our wheel
mirrors. Make it more liberal so we match pretty much any line with
"Downloading" and then eventually something which looks like a whl
file, just in case they keep fiddling with it.
Change-Id: I7965f296cdb1241c96293edd68e84e1d3d78b331
Patch I8eba64c886c187c8652f94735ca6153702203d17 added logic to update
the constraints URL for a project specific file, but adding the file
before committing and submitting the changes was missed, resulting in
git review erroring during the rebase step of submitting the review due
to unstaged files.
Change-Id: I4d87546f12c4a866e9c666e83c42ad8d07a637a3
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
This reverts commit 8b3532c562ddd644de86e0f0929d0b2d88631cfe.
The change mentioned inline has been incoporated upstream with [1]. I
don't think we've managed to replicate the corrupt wheel situation
since.
[1] 0dbab23df9
Change-Id: I58fa0a53939207427f286584e91e1c59d4863992
Some instances have failed due to the repo not being configured for the
expected series job templates. This changes the modified file detection
to only look for the zuul files we care about, then not error out on git
operations if it ends up we can't actually commit and propose changes.
Change-Id: Ic301b039d080dfc0bcbefeecce099c8fd00ad8c5
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
The check-release-approval job currently considers a change being
approved if a release liaison is the change owner, or if a release
liaison approves it in a subsequent vote.
This means that if a release liaison pushes the original change (and
is therefore the change owner), any patchset pushed above the original
one will retain the owner and therefore the approval.
Instead of the change owner, use the committer of the last revision.
Change-Id: I2f7730626a8785b63f88fdf5d507fbd97717b8f3
Local testing passed, but when run in the gate, script execution failed
on the sed expression not being preceded by '-e'.
Change-Id: I02545e1f976f220f197556bdfa6e6225d9bd8d36
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Missed in Id58f439052b4ea6b092b87682576a746433dcc27 that the branch name
passed in when determining the next series name will be of the form
'stable/series', resulting in not finding the next name and job update
logic being skipped. This adjusts the branch name to properly match the
series name.
Change-Id: Ie4102ceb0d12b7d98919ddb89b8e17df1859fa6a
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Currently, we need to update jobs manually after a branch is
created.
When a project is branched, the master branch should then
be pointing to the new named python3 tests.
This should do it.
Change-Id: Id58f439052b4ea6b092b87682576a746433dcc27
When no review is posted yet, Gerrit returns simplified 'labels'
data. In particular it's missing the ['labels']['Code-Review]['all']
dictionary, which we assumed would always be present.
We should only add approvers from the reviews if the 'all' key is
provided, and otherwise just work from the owner email.
Remove all changes pushed to investigate the issue: use a narrow
query again (rather than the /detail call) and no longer catch the
exception.
Change-Id: I13fa07754e38281c63dcf0eceaa4c3b3c2715618
- Use zuul_return fake module to make ansible lint happy, this allows
to remove Zuul import.
- While ansible-lint 4.2.0 is now able to detect playbooks/roles, this
is broken, so don't use it
- move its config out of tox.ini so it can be used by any tools, or
without tox
Change-Id: Ie8935f47db855647e19ae091044e5ac1871f1551
Co-Authored-By: Sorin Sbarnea <ssbarnea@redhat.com>
Co-Authored-By: Andreas Jaeger <aj@suse.com>
Gerrit sometimes returns a partial JSON answer, missing
the details that o=DETAILED_LABELS should trigger. This
results in false negatives in check-release-approval tests.
This cannot be reproduced easily. We put in place a retry
but the issue seems to stick on immediate retries.
As an experiment, this change switches the API call from
/changes/ID with o=DETAILED_LABELS&o=DETAILED_ACCOUNTS to
/changes/ID/detail (which includes these two options, amongst
others), to see if that would workaround the Gerrit issue.
We also remove the retry since it does not improve significantly
the situation.
Change-Id: I4de49da1b48f7b87879102a0e18e97168e39406b