Build and release wheel packages #1723
Conversation
gtristan
requested review from
juergbi,
BenjaminSchubert,
cs-shadow and
abderrahim
as code owners
gtristan
force-pushed
the
tristan/build-wheels
branch
from
d078c88
to
6bb5952
Compare
|
We recently changed the name of the binaries generated by So, we are currently waiting for:
And then we can finally release and tag and see automatically generated and published wheels which include buildbox. |
|
The generated wheels cannot build gnome-build-meta due to #1733. We should resolve that before final release. |
|
Here's a patch that fixes buildbox-casd operation with minimal churn: c529c61 We could alternatively simplify this branch by removing all the _get_host_tool_internal() helpers and setting |
gtristan
force-pushed
the
tristan/build-wheels
branch
from
6bb5952
to
9c1d505
Compare
I've applied the patch to this branch thanks. I think I also like the patch this way because the Global environment setting was unavoidable for setting |
BuildBox is not widely distributed in binary form yet. For convience, add a mechanism to bundle prebuilt binaries in the Python wheel packages. Setting BST_BUNDLE_BUILDBOX=1 when setup.py runs, causes the bundled binaries to be included in the binary package. Its up to the packager to make appropriate binaries available in `src/buildstream/subprojects/buildbox/`. BuildStream will search the package subprojects/ dir when looking for BuildBox binaries on the host in all cases, prioritizing any bundled binaries above other ones on the host. Related to #1712
We are going to build and publish more than just docs, so add _docs to these job names to make it clear.
This updates the CI config to:
* build wheel packages in pre-merge CI
* download BuildBox release binaries to build the wheels
* these can be downloaded as action artifacts
* test built wheel packages in pre-merge CI
* build sdist and wheel packages on each release tag, and upload
them to Test PyPI at https://test.pypi.org/project/BuildStream/
The new workflows are based on examples at
https://cibuildwheel.readthedocs.io/en/stable/setup/, avoiding use of
the GitHub Actions from `pypa/*` as these are not permitted to be used
in apache/buildstream project.
PyPI and Pip use the PEP440 version standard, which uses explicit '.dev', '.a', '.b' and '.rc' suffixes to mark "unstable" releases. BuildStream uses the even/odd convention. When running `pip install` we want Pip to prefer a stable 2.0.0 release over an unstable 2.1.0 release. To make this work, all unstable releases now have a .dev0 suffix automatically added in setup.py, e.g. `2.1.0.dev0`. This is necessary for us to fully automate releases to PyPI from GitHub Actions.
Otherwise, buildbox-casd falls back to its HardLinkStager backend which does not provide sufficient capabilities to build gnome-build-meta. See: #1733
gtristan
force-pushed
the
tristan/build-wheels
branch
from
e693b8b
to
611e8d4
Compare
…link Since renaming the binary tarballs to be more descriptive upstream, we need to fix the download link where we download the binary tarballs. See: https://gitlab.com/BuildGrid/buildbox/buildbox-integration/-/merge_requests/5
Fixes the following error in "Merge actions" workflow:
The workflow is not valid. .github/workflows/merge.yml (Line: 46, Col: 12): Job 'publish_docs' depends on unknown job 'build'.
This is a regression introduced in apache#1723
This updates the CI config to:
Before actually landing this, we need to make some changes:
Fixes #1712