This partially reverts commit
3f961ce202.
This alternative installs wheel with the ensure-pip role instead of in
a separate role. wheel is very closely linked with pip install
operations so this isn't a large overreach of the role.
I suggest this for several reasons; firstly the python-wheel role
doesn't try to install packages, so we end up with mixed system pip
and upstream versions of wheel most of the time. This is the type of
thing that has proven problematic in the past. It also installs via
pip --user; something we've already had problems with tox when for
various reasons roles want to run this as non-zuul user. Using
ensure-pip we keep the packaged versions together.
[1] did try to install wheel with root, but during runtime which
didn't work due to sudo being revoked. This should work for the
existing build-python-release job, because it already includes
ensure-pip in pre-run via playbooks/python/pre.yaml
I believe our conclusion on the ensure-* roles was that requiring
root/become: for installation is OK, but we should have a no-op path
if the tools are found. This is consistent with that approach
(i.e. if you want wheel and can't do sudo, you should pre-install it
on your image using whatever you build that with).
This adds a check to the existing "is pip installed" check to also
check if wheel packages are available. If not we trigger the install
path.
This revealed some issues with RedHat.yaml -- we can always install
Python 3 (packages available for CentOS 7) so remove that check, and
if Ansible is running under Python 2; ensure we install the
dependencies too (not only if it is forced).
Update the documentation to describe that it will enable support for
bdist_wheel, and add a basic sanity test that wheels are produced by
pip. The existing build-python-release job is kept; although it is
modified to use the playbooks/python/pre.yaml playbook as the build
job does.
Change-Id: I2ab11bb45b6b2a49d54db39195228ab40141185c
[1] https://review.opendev.org/#/c/736001/5/roles/build-python-release/tasks/main.yaml
If the download-artifacts query returns more than one build, only
use the most recent one, as earlier builds may be for failed gate
runs and fetching them may fail.
Also, fix one more location which was missing an "artifacts/"
path prefix when returing artifacts.
Change-Id: If988d1f2bea863e0dad267359515018aae25ad45
The recent change to return the artifact URLs for python/js builds
omitted the artifacts/ directory from the URL.
Change-Id: If86749533e73dbfd17317acba22dbd05dff34abb
In the python tarball-post playbook, return an artifact record
for each sdist and wheel that we find.
Change-Id: I328d11a85c55b856d07239129ef95c38f9b1027b
This job is no longer useful as RTD requires an authenticated
end-point now. This has been replaced by the trigger-readthedocs role
in I651efdb093df85cea3ab2eaf1a5a9256c87a2ca4. The dependent change
removes this job from the docs-on-readthedocs template, so it is now
unused.
Change-Id: I794ab68967e8d31d5522acc7484a11d3ebc88ee9
Depends-On: https://review.openstack.org/583834
python-sdist isn't an accurate name since this also builds wheels. Make
a new job named build-python-release.
Also, use zuul_work_dir as the working dir variable.
This role was written rather early and isn't used yet. Change it to use
zuul_work_dir so that it matches other things.
Change-Id: Icfad9ad6ba5c7a0c62a8d5ce243952b81f28a47f
Depends-On: I8dfe5a41710392d6ca8453ce365f674a9d5e4f6e
It's really easy to trigger a build on readthedocs. It doesn't even need
a node, since it's just a single POST.
Change-Id: I8c576c7a26ab123bd70f7a025d8a49a5cb3e2432
If people are using normal tarball jobs to build sdist tarballs, they
can also use a normal job to upload them.
This job will require being passed a dict variable with username and
password, which really should be stored in a secret.
Change-Id: I5747856e54d07a98571db38f1827b3e3cfefe768
OpenStack python tarball building is weird and not done in a manner
consistent with how other folks do it. Make a job that just runs python
setup.py sdist bdist_wheel.
Change-Id: I0df77cdd00b9820bad3b9cde75be9e150057a584
The actions of the playbook don't really have anything to do with tox.
Tarballs go into dist/ whether tox is used or not.
Change-Id: I49d9efaf34644c47df0a1acb6ca108fe4ec99fa4
Sorin Sbarnea