Files
unsupervised-scheduler/.gitea/workflows/cache-probe.yml
T
thatguygriffandClaude Opus 5 a26c481c8f
Cache Service Probe / Cache Service Probe (pull_request) Successful in 2s
CI / Tests (PHP 8.1) (pull_request) Successful in 57s
CI / Tests (PHP 8.2) (pull_request) Successful in 1m2s
CI / No Debug Code (pull_request) Successful in 2s
CI / Tests (PHP 8.3) (pull_request) Successful in 5m1s
CI / Coding Standards (pull_request) Successful in 7m57s
CI / Build Plugin Zip (pull_request) Skipped
CI / PHPStan (pull_request) Successful in 3m4s
Probe what cache endpoint the runner exports
Diagnostic for #178, meant to be deleted once it has answered.

actions/cache refuses to run on these runners, printing its GHES warning,
on both v3 and v4. Two explanations survive and they need different fixes:
cache is off in act_runner's config, so there is no ACTIONS_CACHE_URL and
nothing for the runner's bundle patcher to aim at; or a cache is served
and the patcher does not recognise these bundles, leaving the gate shut,
which would be a runner bug to report upstream.

Whether the runner exports a cache URL separates the two. The job needs no
PHP, so it stays off the slow setup-php path and answers in seconds.

URLs are printed as values since they are plain endpoints. Tokens are
reported as set or unset only, and the second step lists variable names
without values, so no credential reaches the log.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks
2026-08-20 15:13:47 -03:00

54 lines
2.1 KiB
YAML

name: Cache Service Probe
# Temporary diagnostic for #178, to be deleted once it has answered its
# question. actions/cache refuses to run here, printing its GHES warning, on
# both v3 and v4. Two explanations remain and they need different fixes:
#
# 1. Cache is off in act_runner's config, so no ACTIONS_CACHE_URL is exported
# and the runner has nothing to point a patched bundle at. Fix is
# cache.enabled in config.yaml.
# 2. Cache is served, but the runner's bundle patcher does not recognise
# these bundles and so leaves the GHES gate shut. That is a runner bug
# worth reporting upstream.
#
# An exported cache URL tells the two apart.
on:
pull_request:
workflow_dispatch:
jobs:
probe:
name: Cache Service Probe
runs-on: ubuntu-latest
steps:
# Values for the URLs, which are plain endpoints, and presence only for
# the tokens, which are credentials and must not reach the log.
- name: Report cache-related environment
run: |
echo "GITHUB_SERVER_URL = ${GITHUB_SERVER_URL:-<unset>}"
echo "ACTIONS_CACHE_URL = ${ACTIONS_CACHE_URL:-<unset>}"
echo "ACTIONS_RESULTS_URL = ${ACTIONS_RESULTS_URL:-<unset>}"
echo "ACTIONS_CACHE_SERVICE_V2 = ${ACTIONS_CACHE_SERVICE_V2:-<unset>}"
for t in ACTIONS_RUNTIME_TOKEN ACTIONS_CACHE_TOKEN GITHUB_TOKEN; do
if [ -n "${!t:-}" ]; then echo "$t: set"; else echo "$t: unset"; fi
done
# Names only, never values — catches any endpoint variable the runner
# exports under a name this probe did not think to ask for.
- name: List ACTIONS_/GITHUB_ variable names
run: env | grep -E '^(ACTIONS_|GITHUB_)' | sed 's/=.*//' | sort
# Run the real thing alongside, so the warning and the environment that
# produced it sit in one log.
- name: Try actions/cache
uses: actions/cache@v4
with:
path: /tmp/cache-probe
key: cache-probe-${{ github.run_id }}
- name: Runner and version context
run: |
echo "runner.arch = ${{ runner.arch }}"
echo "runner.os = ${{ runner.os }}"