Context
The publish-cask job in release.yml validates the SHA patch with:
grep -q "sha256 \"$ARM64_SHA\"" "$CASK_FILE"
This checks that the SHA exists anywhere in the cask file, not specifically in the darwin_arm64 stanza. Prior to #86, this grep was falsely passing — it found the SHA in the wrong stanza (linux_amd64) and reported success.
With #86 merged the patching logic is correct, but the validation is still not stanza-aware. A future regression in the AWK script could silently pass this check again.
Suggested fix
Replace the grep with a stanza-aware check, e.g.:
if ! awk '/darwin_arm64/{found=1} found && /sha256.*'"$ARM64_SHA"'/{ok=1} END{exit !ok}' "$CASK_FILE"; then
echo "::error::SHA not found in darwin_arm64 stanza"
exit 1
fi
Priority
Low — the core bug is fixed by #86. This is a defense-in-depth improvement
Context
The
publish-caskjob inrelease.ymlvalidates the SHA patch with:This checks that the SHA exists anywhere in the cask file, not specifically in the
darwin_arm64stanza. Prior to #86, this grep was falsely passing — it found the SHA in the wrong stanza (linux_amd64) and reported success.With #86 merged the patching logic is correct, but the validation is still not stanza-aware. A future regression in the AWK script could silently pass this check again.
Suggested fix
Replace the grep with a stanza-aware check, e.g.:
Priority
Low — the core bug is fixed by #86. This is a defense-in-depth improvement