CI: warm Ghostty cache on main so PRs share it

[dhilgaertner]

Closes #177

Summary

• Add .github/workflows/cache-warm.yml triggered on push: main that does checkout → setup-xcode → setup-zig → actions/cache lookup → make ghostty (guarded by cache-hit != 'true'). No swift build / tests.
• Uses the same cache key literal as ci.yml / release.yml (ghostty-${runner.os}-${runner.arch}-${submodule-sha}) so PRs and tag releases start hitting the warm slot automatically via the default-branch fallback.
• concurrency: cancel-in-progress: false so an in-flight real Ghostty build isn't killed by a later merge. No path filter — unchanged-SHA runs are ~1 min cache-hit no-ops anyway.

Why option 2 (dedicated workflow) over adding push: main to ci.yml

Avoids re-running the full Build & Test matrix on every merge. When vendor/ghostty hasn't changed since the last warm, the job is effectively a no-op.

Test plan

• After merge, confirm the "Cache Warm" run on main completes and its "Cache Ghostty framework" post-job step logs a cache write for ghostty-macOS-ARM64-<sha>.
• Open a follow-up PR (no Ghostty submodule bump) and verify its "Cache Ghostty framework" step reports cache-hit: true and "Build Ghostty" is skipped.
• Push a docs-only commit to main and confirm "Cache Warm" finishes in ~1 min with a cache hit (no new cache entry created).

🤖 Generated with Claude Code

[dgershman]

Code & Security Review

Security Review

Strengths:

• No secrets, credentials, or sensitive data involved — this is a pure build-cache workflow
• No elevated permissions requested (defaults to read-only)
• Uses pinned action versions (actions/checkout@v4, actions/cache@v4)

Concerns:

• None

Code Quality

• Cache key ghostty-${{ runner.os }}-${{ runner.arch }}-${{ steps.ghostty-sha.outputs.sha }} is identical across all three workflows (ci.yml:40, release.yml:137, cache-warm.yml:40) — cache sharing will work correctly via GitHub's default-branch fallback
• Ghostty SHA extraction step, Zig setup, Xcode version, runner (macos-15), and the unset ZIG_LOCAL_CACHE_DIR ZIG_GLOBAL_CACHE_DIR guard are all consistent with existing workflows
• concurrency.cancel-in-progress: false is the right call — avoids killing a real Ghostty build mid-flight
• if: steps.ghostty-cache.outputs.cache-hit != 'true' means repeated pushes with the same submodule SHA are fast no-ops (~1 min)
• No path filter is a reasonable tradeoff given the no-op cost is low

Summary Table

Priority	Issue
Green	Consider extracting the shared Ghostty cache steps into a composite action to reduce duplication across the three workflows (not blocking)

Recommendation: Approve — clean, minimal workflow that exactly mirrors existing cache patterns. No security or correctness concerns.

[dgershman]

Code & Security Review

Critical Issues

None.

Security Review

Strengths:

• No secrets or credentials exposed
• Cache key is deterministic and scoped to submodule SHA — no cache poisoning vector
• cancel-in-progress: false prevents an attacker from using rapid pushes to cancel legitimate builds
• Workflow triggers only on push to main (protected branch), not on external PRs

Concerns:

• None identified

Code Quality

• Cache key format (ghostty-${{ runner.os }}-${{ runner.arch }}-${{ steps.ghostty-sha.outputs.sha }}) matches ci.yml and release.yml exactly — cache sharing will work as intended
• ZIG_VERSION matches the other workflows (0.15.2)
• Xcode version, runner OS, and action versions are consistent with the existing CI matrix
• The unset ZIG_LOCAL_CACHE_DIR ZIG_GLOBAL_CACHE_DIR in the build step matches the pattern in other workflows
• Concurrency group is scoped to cache-warm-${{ github.ref }} which is appropriate — only one warm job per ref at a time

Summary Table

Priority	Issue
Green	No path filter — docs-only pushes still trigger the job, but as noted in the PR description these are ~1 min no-ops due to cache hit. Acceptable trade-off for simplicity.

Recommendation: Approve — this is a clean, minimal workflow that correctly shares the Ghostty framework cache with PR and release builds. No security or correctness concerns.