pat-s
228459c0ba
All checks were successful
ci/crow/cron/process-updates-alpine-323-arm64 Pipeline was successful
ci/crow/cron/process-updates-redhat-9-arm64 Pipeline was successful
ci/crow/cron/process-updates-ubuntu-2204-amd64 Pipeline was successful
ci/crow/cron/process-updates-ubuntu-2204-arm64 Pipeline was successful
ci/crow/cron/process-updates-ubuntu-2404-amd64 Pipeline was successful
ci/crow/cron/process-updates-ubuntu-2404-arm64 Pipeline was successful
ci/crow/cron/process-updates-redhat-10-amd64 Pipeline was successful
ci/crow/cron/process-updates-redhat-10-arm64 Pipeline was successful
ci/crow/cron/process-updates-alpine-322-amd64 Pipeline was successful
ci/crow/cron/process-updates-alpine-322-arm64 Pipeline was successful
ci/crow/cron/process-updates-redhat-9-amd64 Pipeline was successful
ci/crow/cron/process-updates-alpine-323-amd64 Pipeline was successful
ci/crow/cron/process-updates-redhat-8-arm64 Pipeline was successful
ci/crow/cron/process-updates-redhat-8-amd64 Pipeline was successful
## Summary While cleaning this up I noticed the script **defined** `purge_cdn_cache()` but never **called** it. Every CI run only declared the helper and exited cleanly without issuing a single curl. The PACKAGES freshness on cran.devxy.io / cran.rpkgs.com has been carried entirely by R's `Cache-Control: no-cache` header on the index files. Fixes in one shot: 1. **Actually run the purge.** The shifted args (`api_key`, `arch`, `os_id`, `domain…`) are now consumed inline and a curl POST is issued per (domain × resource). 2. **Drop `set -x`** — leaked the `AccessKey:` header into job logs. 3. **Drop the Python URL-encoder.** `curl -G --data-urlencode "url=…" --data "async=false" https://api.bunny.net/purge` does the same with no Python. The workflow purge steps can later switch from `alpine:3.23 + apk add bash curl` to a slimmer curl-only image. 4. **Add `src/contrib/Meta/archive.rds`** to the purged resource list. It's rewritten on every `process_cran_updates` run (see README) and was being served stale. ## Risks - This is the **first time** the script actually purges anything. If anything else (e.g. a downstream service) relied on the no-op behavior, this PR is the moment it stops being silent. I don't see any such caller. - Edge cache miss right after a purge means an origin S3 fetch — minor latency uptick on the first request per region per resource. Reviewed-on: #78
44 lines
963 B
Shell
44 lines
963 B
Shell
#!/usr/bin/env bash
|
|
#
|
|
# Purge BunnyCDN edge cache for the index files of one ARCH+OS_ID
|
|
# combination across one or more domains.
|
|
#
|
|
# Usage:
|
|
# purge_cdn_cache.sh <BUNNYNET_API_KEY> <ARCH> <OS_ID> <domain> [<domain>...]
|
|
#
|
|
set -euo pipefail
|
|
|
|
if (( $# < 4 )); then
|
|
echo "usage: $0 <api_key> <arch> <os_id> <domain> [<domain>...]" >&2
|
|
exit 2
|
|
fi
|
|
|
|
api_key="$1"
|
|
arch="$2"
|
|
os_id="$3"
|
|
shift 3
|
|
|
|
resources=(
|
|
"src/contrib/PACKAGES"
|
|
"src/contrib/PACKAGES.gz"
|
|
"src/contrib/PACKAGES.rds"
|
|
"src/contrib/PACKAGES.db"
|
|
"src/contrib/Meta/archive.rds"
|
|
)
|
|
|
|
purge_one() {
|
|
local target="$1"
|
|
# --data-urlencode encodes value of `url=` for us; -G forces GET.
|
|
curl -sS -G -X POST \
|
|
-H "AccessKey: ${api_key}" \
|
|
--data-urlencode "url=${target}" \
|
|
--data "async=false" \
|
|
"https://api.bunny.net/purge"
|
|
echo
|
|
}
|
|
|
|
for domain in "$@"; do
|
|
for resource in "${resources[@]}"; do
|
|
purge_one "https://${domain}/${arch}/${os_id}/latest/${resource}"
|
|
done
|
|
done
|