GHA: fix caching old mingw-w64 toolchains in the Windows workflow#13856
GHA: fix caching old mingw-w64 toolchains in the Windows workflow#13856vszakats wants to merge 3 commits intocurl:masterfrom
Conversation
|
Meanwhile caches are almost never hit though the key exists, and often still attempting to save the cache (and often failing), GitHub accumulated a large collection of these Windows caches. The behaviour is explained here, though it assumes that a key cached on the main branch is found by branches, which they don't seem to be for the curl Windows workflow: There is a list of Windows-related issues in the action's repo, this one is still open: Though in curl's case a cache write also fails often and inexplicably. |
|
I'm manually purging a bunch of them to go back under 10GB total. |
|
cache@v2 seemed to save the cache then find the key correctly, but then blew up when extracting the cache: Ref: https://github.com/curl/curl/actions/runs/9337833329/job/25700218626 This was the tar command: Then back to square one: Ref: https://github.com/curl/curl/actions/runs/9337833329/job/25700218908#step:20:2 |
|
v2 with unixy path notation "works" because there is nothing in the cache tarballs. |
|
It seems that the cache "version" is different each time, which makes the action create new cache entries on every run: Ref: https://github.com/curl/curl/actions/runs/9338157000/job/25701293515#step:2:56 curl -L -A curl \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/repos/curl/curl/actions/caches | jqManual: |
|
It looks like this line in one of the step: echo "PATH=$(cygpath "${USERPROFILE}")/my-cache/mingw64/bin:/c/msys64/usr/bin:$PATH" >> "$GITHUB_ENV"makes the caching post-script confused, when it fails to find zstd, and which makes the "version" hash different from the pre-script, where zstd is present: Ref: https://github.com/curl/curl/actions/runs/9338773353/job/25702416548#step:16:30 while in the pre-script: Ref: https://github.com/curl/curl/actions/runs/9339474086/job/25704019595#step:2:39 (This doesn't explain why it was working sometimes.) I couldn't figure out how to undo the above line manually, After replacing the Another, earlier issue was that |
|
Initial post for future reference: Caching continues to fail on Windows workflows: Ref: https://github.com/curl/curl/actions/runs/9334517760/job/25697464520?pr=13622#step:2:10 In the same PR, caching works fine on Linux: https://github.com/curl/curl/actions/runs/9334517768/job/25692846508?pr=13622#step:2:25 It's probably a stupid error on my part when implementing this. Caching (almost?) always fails to find the cache: |
This makes it not rely on specific absolute paths.
GITHUB_ENV interferes with actions/cache's post-job, resulting in an unstable cache entry "version" due to not finding the same tools (e.g. zstd) as in the pre-job.
stop altering the
PATHviaGITHUB_ENV. This confused theactions/cachepost-job, which needs to run in the exact sameenvironment as its pre-job, to have a consistent cache entry "version"
hash. Altering the
PATHviaGITHUB_ENVspills into the thepost-job and breaks this hash. GHA doesn't reset the env automatically
and I have not found a way to do it manually.
add double-quotes where missing.
move cache directory under
USERPROFILEto not rely on absolutepaths.
make cache directory flatter and versionless.
Follow-up to 0914d8a #13759
Closes #13856