fix(ci): partition pnpm caches by runner

[Jesssullivan]

Summary:

• isolate workspace-local pnpm store caches by runner name on self-hosted honey runners
• stop honey-sk-1 and honey-sk-2 from restoring each others pnpm store snapshots
• keep the existing workspace-local store model introduced for the self-hosted lane

Root cause:
The publish workflow test job restored a cache snapshot created on another runner, and pnpm then tried to copy from an absolute store path under honey-sk-1 while running on honey-sk-2. Partitioning the cache key by runner name removes that cross-runner contamination.

Validation:

• observed publish run 24519258595 fail in Install dependencies with ERR_PNPM_ENOENT referencing honey-sk-1 from a honey-sk-2 job
• patched CI and publish cache keys to include runner.name

[greptile-apps]

Greptile Summary

This PR fixes cross-runner pnpm cache contamination on self-hosted runners (honey-sk-1, honey-sk-2) by adding runner.name to the cache key and restore-keys in both ci.yml and publish.yml. The root cause — a job on honey-sk-2 restoring a cache snapshot written by honey-sk-1 with a different absolute store path — is directly addressed.

Confidence Score: 5/5

Safe to merge — the fix correctly isolates self-hosted runner caches and only remaining feedback is a P2 suggestion to add a runner-agnostic restore-key fallback tier.

The targeted bug (cross-runner store path contamination) is fully fixed. The two comments are P2 style suggestions about improving cache hit rate on GitHub-hosted fallback runners, which is a minor efficiency concern that does not affect correctness or self-hosted CI.

No files require special attention — both workflow changes are consistent and focused.

Important Files Changed

Filename	Overview
.github/workflows/ci.yml	Cache keys in both the test (matrix) and build jobs now include runner.name, correctly isolating self-hosted runner stores; however, on GitHub-hosted fallback runners runner.name varies per job, causing full cache misses.
.github/workflows/publish.yml	The test job's pnpm cache key gains runner.name consistently with ci.yml; publish/download jobs are unaffected as they use artifact upload/download instead of pnpm caching.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Job starts on runner] --> B{runner.name in cache key}
    B -->|Before fix - key has no runner.name| C[Cache lookup: OS + node + pnpm + hash]
    B -->|After fix - key includes runner.name| D[Cache lookup: OS + runner.name + node + pnpm + hash]

    C --> E{Cache hit?}
    E -->|Yes - may be from another runner| F[Restore alien store abs path = honey-sk-1]
    E -->|No| G[Cold install]
    F --> H[pnpm copy from wrong abs path ERR_PNPM_ENOENT]

    D --> I{Exact hit on same runner?}
    I -->|Yes| J[Restore own store abs path matches]
    I -->|No - restore-keys prefix match| K{Runner type?}
    K -->|Self-hosted stable runner.name| L[Partial hit from same runner]
    K -->|GitHub-hosted unique runner.name per run| M[No hit at all - cold install]

    J --> N[pnpm install fast]
    L --> N
    G --> N
    M --> N

Loading

_{Reviews (1): Last reviewed commit: "fix(ci): partition pnpm caches by runner" | Re-trigger Greptile}

[greptile-apps]

GitHub-hosted runner cache cold-start on fallback path

When PRIMARY_LINUX_RUNNER_LABELS_JSON is unset and jobs fall back to ubuntu-latest, GitHub provisions a fresh VM each run with a distinct runner.name (e.g. GitHub Actions 3, GitHub Actions 17). Because both the exact key and the restore-keys prefix embed that unique name, neither will match any prior run's entry — every job on GitHub-hosted runners will see a complete cache miss. Before this change the key was runner-agnostic, so restore-keys provided partial hits. The fix is correct for self-hosted runners; just be aware the fallback lane loses cache re-use entirely unless a runner-agnostic restore-key tier is added, e.g.:

restore-keys: |
  ${{ runner.os }}-${{ runner.name }}-node-${{ matrix.node-version }}-pnpm-${{ env.PNPM_VERSION }}-
  ${{ runner.os }}-node-${{ matrix.node-version }}-pnpm-${{ env.PNPM_VERSION }}-

[greptile-apps]

Same GitHub-hosted fallback cache miss (publish test job)

Mirrors the ci.yml concern: the single restore-keys entry includes runner.name, so GitHub-hosted fallback runs will always have a cold cache. Adding a runner-agnostic restore-key tier would preserve partial hits on that path:

restore-keys: |
  ${{ runner.os }}-${{ runner.name }}-node-${{ env.DEFAULT_NODE_VERSION }}-pnpm-${{ env.PNPM_VERSION }}-
  ${{ runner.os }}-node-${{ env.DEFAULT_NODE_VERSION }}-pnpm-${{ env.PNPM_VERSION }}-