[th/ktoolbox-wheel-url] ktoolbox: install ktoolbox package using wheel URL #220
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously, we used git+https:// URL with a fixed commit SHA to the ktoolbox version. This has the benefit that the commit SHA cryptographically encodes the code we are going to pull and build. In jenkins CI, we reuse a venv and install it via `pip install -r requirements.txt`. Sometimes this venv gets corrupted. It is unclear why this happens. Could this be related to rebuilding the ktoolbox package from a git checkout? Try to use instead the wheel file. ktoolbox automatically builds a wheel file, pushes it to a "gh-pages" branch ([1]) and exposes it on github pages ([2]). See the README ([3]) how that can be used. We could directly refer to the github pages file using URL https://thom311.github.io/ktoolbox/wheels/141.7708daaf4f8c/ktoolbox-0.8.0-py3-none-any.whl but instead get to the exactly same file via https://raw.githubusercontent.com/thom311/ktoolbox/8d5ce796bf07cf7a612084cfa7a6f4387ef0640c/wheels/141.7708daaf4f8c/ktoolbox-0.8.0-py3-none-any.whl This has the benefit that 8d5ce796bf07cf7a612084cfa7a6f4387ef0640c cryptographically ensures that we are referring to a certain commit in github, which I trust to contain the code build from commit 7708daaf4f8c. Technically, unlike the git+https URL, this does not ensure that the wheel file was really build based on commit 7708daaf4f8c. But I know that this was the case for commit 8d5ce796bf07cf7a612084cfa7a6f4387ef0640c, so we can have a slightly higher confidence to pull what we expect. [1] https://github.com/thom311/ktoolbox/commits/gh-pages/ [2] https://thom311.github.io/ktoolbox/wheels/ [3] https://github.com/thom311/ktoolbox/blob/f083da6fa0cc2deb47751f201dc6dcbb81616f77/README.md#installation-and-wheel-files Signed-off-by: Thomas Haller <thaller@redhat.com>
|
LGTM llet's try it. |
thom311
changed the title
thom311
added a commit
to thom311/dpu-operator
that referenced
this pull request
Jun 3, 2025
There are various improvements. One changes is [1], which installs the ktoolbox dependency via a https URL to the pre-build wheel file. Maybe that helps with the corruption of /tmp/tft-venv that we sometimes see. [1] ovn-kubernetes/kubernetes-traffic-flow-tests#220
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, we used git+https:// URL with a fixed commit SHA to the ktoolbox version. This has the benefit that the commit SHA cryptographically encodes the code we are going to pull and build.
In jenkins CI, we reuse a venv and install it via
pip install -r requirements.txt. Sometimes this venv gets corrupted. It is unclear why this happens. Could this be related to rebuilding the ktoolbox package from a git checkout?Try to use instead the wheel file. ktoolbox automatically builds a wheel file, pushes it to a "gh-pages" branch ([1]) and exposes it on github pages ([2]). See the README ([3]) how that can be used.
We could directly refer to the github pages file using URL
https://thom311.github.io/ktoolbox/wheels/141.7708daaf4f8c/ktoolbox-0.8.0-py3-none-any.whl
but instead get to the exactly same file via
https://raw.githubusercontent.com/thom311/ktoolbox/8d5ce796bf07cf7a612084cfa7a6f4387ef0640c/wheels/141.7708daaf4f8c/ktoolbox-0.8.0-py3-none-any.whl
This has the benefit that 8d5ce796bf07cf7a612084cfa7a6f4387ef0640c cryptographically ensures that we are referring to a certain commit in github, which I trust to contain the code build from commit 7708daaf4f8c. Technically, unlike the git+https URL, this does not ensure that the wheel file was really build based on commit 7708daaf4f8c. But I know that this was the case for commit 8d5ce796bf07cf7a612084cfa7a6f4387ef0640c, so we can have a slightly higher confidence to pull what we expect.
[1] https://github.com/thom311/ktoolbox/commits/gh-pages/
[2] https://thom311.github.io/ktoolbox/wheels/
[3] https://github.com/thom311/ktoolbox/blob/f083da6fa0cc2deb47751f201dc6dcbb81616f77/README.md#installation-and-wheel-files