Closed frenck closed 1 week ago
Same thing with 3.13.0b2:
Run actions/setup-python@v5
Installed versions
Version ~3.13.0-0 was not found in the local cache
Version ~3.13.0-0 is available for downloading
Download from "https://github.com/actions/python-versions/releases/download/3.13.0-beta.2-9442465578/python-3.13.0-beta.2-linux-22.04-x64.tar.gz"
Extract downloaded archive
/usr/bin/tar xz --warning=no-unknown-keyword --overwrite -C /home/runner/work/_temp/ce7441c9-c7c3-405b-8d85-f47fd5f8a722 -f /home/runner/work/_temp/8c32cd5a-e1e8-4874-ac7a-a0c200b8ba14
gzip: stdin: not in gzip format
/usr/bin/tar: Child returned status 1
/usr/bin/tar: Error is not recoverable: exiting now
Error: The process '/usr/bin/tar' failed with exit code 2
https://github.com/pypa/pip/actions/runs/9443536250/job/26007467646
Both 3.12.4 and 3.13.0-beta.2 were released on https://github.com/actions/python-versions a couple of hours ago:
Seems like the header is incorrect?
λ Downloads » xxd python-3.12.4-linux-22.04-x64.tar.gz | less | head -1
00000000: 1fef bfbd 0800 0000 0000 0003 efbf bd3c ...............<
1fef
isn't a valid magic number for gzip
(file
is unaware of anything using it) so I'm not sure if this is a weird case of bitflip? Rest of the header seems fine.
the same with macos and win archives :
Version 3.12 was not found in the local cache
Version 3.12 is available for downloading
Download from "https://github.com/actions/python-versions/releases/download/3.12.4-9442300799/python-3.12.4-darwin-x64.tar.gz"
Extract downloaded archive
/usr/bin/tar xz -C /Users/runner/work/_temp/f2bc8ae4-bdba-46b8-823a-bd909c45dd1b -f /Users/runner/work/_temp/623e67b2-44e6-4a3d-8516-abe6e9d12231
tar: Error opening archive: Unrecognized archive format
Error: The process '/usr/bin/tar' failed with exit code 1
Seems like the header is incorrect?
The file is completely garbled. It mostly consists of ef bf bd
patterns.
I have noticed this is working in ubuntu-latest
runner, but not on my self-hosted
runner, both using the same container: ubuntu:24.04
for testing purposes.
I have noticed this is working in
ubuntu-latest
runner, but not on myself-hosted
runner, both using the samecontainer: ubuntu:24.04
for testing purposes.
The hosted runners have an cached toolchain with multiple versions of python already installed. The action is using that instead downloading an version. The selfhosted image does not have sush toolchain.
GitHub hosted is running on 50Gb+ VMs in Azure to minimize download and install cycles.
Edit: Info location hosted runner "image": https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md
The file is completely garbled. It mostly consists of ef bf bd patterns.
Ah, nice spotting.
However it's weird that the deflate header is kept as-is while the 1f
bytes are correct.
However it's weird that the deflate header is kept as-is while the
1f
bytes are correct.
The ef bf bd
pattern is a specific symbol: https://www.cogsci.ed.ac.uk/~richard/utf-8.cgi?input=%EF%BF%BD&mode=char
That is the symbol you usually see when UTF-8 is being displayed as ASCII. It looks the files have been treated as text causing all the non-ASCII (i.e. binary) data being treated as unprintable characters thus corrupting it in the process.
Please let us know what is the fix ?
@jasmitha-meka as a workaround you can pin the version 3.12.3
Can confirm pinning version to 3.12.3
allows our actions to pass, thanks all.
tested all assets from https://github.com/actions/python-versions/releases/tag/3.12.4-9442300799
NONE OF THEM ARE WORKING AS EXPECTED.
This might be related to the actions/upload-artifact
new version (v4). We've had problems in the past with incompatibilities, wrong compression mechanisms etc. They upgraded the version not that long ago: https://github.com/actions/python-versions/commit/c990e6da9586f6b33bf19aba61c934ded6ec28c5
This commit is dated on May 22nd whereas the last previous release is from May 9th
Hello @frenck Thankyou for creating this issue. we are working on the fix and will get back to you sooner.
The hashes do not match at all.
3.13.0-beta.2
$ sha256sum -c hashes.sha256
python-3.13.0-beta.2-darwin-arm64.tar.gz: FAILED
python-3.13.0-beta.2-darwin-x64.tar.gz: FAILED
python-3.13.0-beta.2-linux-20.04-x64.tar.gz: FAILED
python-3.13.0-beta.2-linux-22.04-x64.tar.gz: FAILED
python-3.13.0-beta.2-linux-24.04-x64.tar.gz: FAILED
python-3.13.0-beta.2-win32-x64.zip: FAILED
python-3.13.0-beta.2-win32-x86.zip: FAILED
sha256sum: WARNING: 7 computed checksums did NOT match
3.12.4
$ sha256sum -c hashes.sha256
python-3.12.4-darwin-arm64.tar.gz: FAILED
python-3.12.4-darwin-x64.tar.gz: FAILED
python-3.12.4-linux-20.04-x64.tar.gz: FAILED
python-3.12.4-linux-22.04-x64.tar.gz: FAILED
python-3.12.4-linux-24.04-x64.tar.gz: FAILED
python-3.12.4-win32-x64.zip: FAILED
python-3.12.4-win32-x86.zip: FAILED
sha256sum: WARNING: 7 computed checksums did NOT match
The files are also double in size than the previous versions because of the corruption. The source archives are fine.
3.12.3
$ sha256sum -c hashes.sha256
python-3.12.3-darwin-arm64.tar.gz: OK
python-3.12.3-darwin-x64.tar.gz: OK
python-3.12.3-linux-20.04-x64.tar.gz: OK
python-3.12.3-linux-22.04-x64.tar.gz: OK
python-3.12.3-linux-24.04-x64.tar.gz: OK
python-3.12.3-win32-x64.zip: OK
python-3.12.3-win32-x86.zip: OK
Download artifact will corrupt files if there are any matching file names when merging multiple, this looks suspiciously like that. https://github.com/actions/download-artifact/issues/298
The manifest that holds broken releases has been reverted by @HarithaVattikuti : https://github.com/actions/python-versions/pull/282
This removes 3.12.4
& 3.13.0b2
. (but installing latest 3.12 or dev 3.13 now works again - using 3.12.3
& 3.13.0b1
).
https://github.com/actions/python-versions/pull/285 should resolve the issue.
Hello Everyone, we merged the fix for this issue. Please validate from your end and confirm.
Thanks @aparnajyothi-y, I can confirm the latest release / manifest fixes the issue in #863 (some GH-hosted workers) and #884 (all GH-hosted workers).
All looks good for us at flake8-pyi and typeshed now -- thanks @aparnajyothi-y!
CI now passes at pywin32
for Python 3.13-dev as well! https://github.com/mhammond/pywin32/pull/2260
Some good confirmations above. Can confirm it works on our end too. Closing the issue for that reason.
Thanks for the fix! ❤️
../Frenck
Description: A clear and concise description of what the bug is.
https://github.com/home-assistant/core/actions/runs/9442844577/job/26006478894?pr=119255
Action version: Specify the action version
actions/setup-python@v5.1.0
Platform:
Runner type:
Tools version:
3.12 (resulting in 3.12.4 right now)
Repro steps:
A description with steps to reproduce the issue. If your have a public example or repo to share, please provide the link.
https://github.com/home-assistant/core/blob/159503b8d37fbc46a353287416a640ad07c2cced/.github/workflows/ci.yaml#L230-L235
Expected behavior: A description of what you expected to happen.
Actual behavior: A description of what is actually happening.