Current release-announce job proceeds with installing the package being
released, just in order to compute the "description" of the package and
include it in the announcement. This is costly and error-prone, for very
little gain.
This change removes the costly computation of the "description". The
"project_name" was overridden by $ZUUL_PROJECT anyway. The email
template already has logic to skip the description if it's not provided.
Change-Id: I5a60556f7d321fd4c37f1424509469da28a1eec9
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
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
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
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
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
Git repo origins are now removed in CI jobs, so our detection of project
short name from looking at the git remote now fails. This resulted in
release announcements linking to "null" instead of the actual project
location [0].
This updates the script logic to detect if that is the case and fall
back to getting the repo name from the directory, which should be safe
in a CI job since there is no manipulation of the clones repo directory
name.
Also cleans up an unused variable that was left from a previous
refactoring.
[0] http://lists.openstack.org/pipermail/release-announce/2019-December/008306.html
Change-Id: I84e2cf258e9bc4541b7edde55a22a4be24bdb232
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Our announce email included a few errors in the paths provided. If the
git remote.origin.url ended with ".git" the tarball path was wrong. We
were also using the package name for git and doc paths incorrectly. This
fixes the name used so the resulting links are correct.
Story: #2005279
Task: #30131
Change-Id: I7a64761778b7391c0f3188b1177f03a7e712bd2a
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
A few errors were causing the bashate job to fail. This corrects those
errors and also addresses the reported warnings for a clean build.
Change-Id: Ibc5c4f006d264e2f0a4c1b8186b5e313d2905561
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>