Description
Yesterday, Git v2.47.0 came out.
I wanted to trigger the update-git-version-and-manual-pages workflow immediately, but due to the mistakes I built into #1899, I had to hold off until d4f88c1 & 0340ff6 fixed them. Directly after that, I finally triggered the run. It failed because of a pair of bugs, one in Git v2.47.0, followed by another one in the workflow; The latter should be addressed by #1900, the former by gitgitgadget/git#1812.
But here's the thing: The front page did not update to reflect that the latest Git version is v2.47.0. It still showed v2.46.2 as the latest one.
At first, I thought that there was a problem deploying (which should have succeeded despite the failed broken-link check), but no:
[...]
Uploaded bytes 382839308
Finished uploading artifact content to blob storage!
SHA256 hash of uploaded artifact zip is 331a328e6793ca6f74548d81a3445d1fb11d387ad8f662ebbe735f620544e52e
Finalizing artifact upload
Artifact github-pages.zip successfully finalized. Artifact ID 2024842855
Artifact github-pages has been successfully uploaded! Final size is 382839308 bytes. Artifact ID is 2024842855
Artifact download URL: https://github.com/git/git-scm.com/actions/runs/11219313103/artifacts/2024842855
Run actions/deploy-pages@v4
Fetching artifact metadata for "github-pages" in this workflow run
Found 1 artifact(s)
Creating Pages deployment with payload:
{
"artifact_id": 2024842855,
"pages_build_version": "0340ff620437b56700606fa16fd7a1ea8379c36a",
"oidc_token": "***"
}
Created deployment for 0340ff6, ID: 0340ff6
Getting Pages deployment status...
Reported success!
[...]
So I looked for the newly-added https://git-scm.com/docs/platform-support and it was there (broken link and all)!
It totally looked like the page was still cached. To exclude my browser cache from the possible culprits, I started a different browser (one that I use really, really rarely, therefore there was 0% chance that it had the page in its cache), but still: Latest source Release v2.46.2.
Then I thought that maybe the Cloudflare cache-purging did not work correctly? But no:
[...]
▼ Run curl "https://api.cloudflare.com/client/v4/zones/$CLOUDFLARE_ZONE/purge_cache"
curl "https://api.cloudflare.com/client/v4/zones/$CLOUDFLARE_ZONE/purge_cache"
-H "Authorization: ***"
-H "Content-Type: application/json"
-d '{ "purge_everything": true }'
shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
env:
GITHUB_PAGES: true
HUGO_VERSION: 0.134.3
PAGEFIND_VERSION: 1.1.1
CLOUDFLARE_ZONE: ***
CLOUDFLARE_TOKEN: ***
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 148 0 120 100 28 281 65 --:--:-- --:--:-- --:--:-- 348
{
"result": {
"id": "***"
},
"success": true,
"errors": [],
"messages": []
}
[...]
Then I thought that we may be doing something differently from the Docker Action we used previously to purge the Cloudflare cache, but no:
HTTP_RESPONSE=$(curl -sS "https://api.cloudflare.com/client/v4/zones/${CLOUDFLARE_ZONE}/purge_cache" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer ${CLOUDFLARE_TOKEN}" \
-w "HTTP_STATUS:%{http_code}" \
"$@")The "$@" resolves to {"purge_everything":true} because of this line.
That looks pretty much the same to what we now do:
curl "https://api.cloudflare.com/client/v4/zones/$CLOUDFLARE_ZONE/purge_cache" \
-H "Authorization: Bearer $CLOUDFLARE_TOKEN" \
-H "Content-Type: application/json" \
-d '{ "purge_everything": true }'The only difference I see is that we ignore the HTTP status (without -f, cURL will produce an exit code of 0 for pages that 404, try this at home: curl -I https://git-scm.com/123; echo $?).
Render me puzzled. I will trigger the update-download-data workflow manually after releasing Git for Windows v2.47.0 and then pay close attention whether the download link on https://git-scm.com/ changes. If not, I am afraid that we'll have to dig a little deeper to figure out why the Cloudflare caches are not purged as desired.
/cc @ttaylorr