build-whisper-stt.yml keys its build cache on the runner image so that a Xcode/SDK roll invalidates it:
key: whisper-stt-build-${{ matrix.tag }}-${{ env.ImageOS }}-${{ env.ImageVersion }}-${{ hashFiles(...) }}with a comment explaining exactly why that matters:
the runner image version ($ImageOS/$ImageVersion) is part of the key AND the restore-keys prefix because CMake bakes absolute toolchain paths (e.g. the Xcode SDK's libz.tbd) into the cached build tree — when GitHub rolls the image's Xcode/SDK, those paths vanish and a restored tree fails with "No rule to make target …libz.tbd". Scoping the cache to the image version auto-busts it on every toolchain roll.
It has never worked. Both expressions evaluate to the empty string, on every platform, since the line was written.
The evidence is the repository's own cache list (gh api repos/getopenscreen/openscreen/actions/caches):
whisper-stt-build-win32-x64---2ca5d2c75aac59ca…
whisper-stt-build-darwin-x64---2ca5d2c75aac59ca…
whisper-stt-build-linux-x64---2ca5d2c75aac59ca…
whisper-stt-build-darwin-arm64---2ca5d2c75aac59ca…
Three consecutive hyphens where <ImageOS>-<ImageVersion>- should be.
Why: the env expression context contains only what a workflow, job or step env: block defined. ImageOS and ImageVersion are set by the runner into its own process environment, so they are visible to run: steps as shell variables but not to ${{ env.… }}.
Consequence: the cache is keyed on matrix.tag + the CMakeLists hash alone. After a GitHub image roll, a stale tree with dead absolute SDK paths is restored, and the failure mode is the one the comment predicts — No rule to make target …libz.tbd, on a build nobody changed.
Fix, the same shape used in build-onnxruntime-macos.yml (#595):
- name: Read the runner image
id: image
run: echo "tag=${ImageOS:-unknown}-${ImageVersion:-unknown}" >> "$GITHUB_OUTPUT"then ${{ steps.image.outputs.tag }} in both key: and restore-keys:.
Worth grepping the other workflows for env.Image at the same time — this idiom tends to be copied.
build-whisper-stt.ymlkeys its build cache on the runner image so that a Xcode/SDK roll invalidates it:with a comment explaining exactly why that matters:
It has never worked. Both expressions evaluate to the empty string, on every platform, since the line was written.
The evidence is the repository's own cache list (
gh api repos/getopenscreen/openscreen/actions/caches):Three consecutive hyphens where
<ImageOS>-<ImageVersion>-should be.Why: the
envexpression context contains only what a workflow, job or stepenv:block defined.ImageOSandImageVersionare set by the runner into its own process environment, so they are visible torun:steps as shell variables but not to${{ env.… }}.Consequence: the cache is keyed on
matrix.tag+ the CMakeLists hash alone. After a GitHub image roll, a stale tree with dead absolute SDK paths is restored, and the failure mode is the one the comment predicts —No rule to make target …libz.tbd, on a build nobody changed.Fix, the same shape used in
build-onnxruntime-macos.yml(#595):then
${{ steps.image.outputs.tag }}in bothkey:andrestore-keys:.Worth grepping the other workflows for
env.Imageat the same time — this idiom tends to be copied.