mirror of
https://github.com/ComposioHQ/composio.git
synced 2026-09-22 11:46:35 +08:00
64acec65b6
This PR: - fixes the `ts.build.yml` push trigger, which still pointed at `master`: the repo's default branch is `next`, so the workflow has not run on push since 2025-10-24 and never populated the turbo/pnpm caches that PR runs restore from (GitHub cache isolation lets PRs read base-branch caches, but not other PRs') - fixes the same stale `master` push trigger in `py.check.yaml` (all other workflows already list `next`) - adds a `cache-save` input (default `'true'`, preserving current behavior for every other consumer) to the `setup-node-pnpm-bun` composite action, swapping `actions/cache` for `actions/cache/restore` (same repo, same v6.1.0 SHA pin) when disabled - wires `cache-save` in `ts.build.yml` so only push runs on `next` persist caches: PR-scoped saves are invisible to other branches, so they only cost post-job time and evict default-branch entries from the 10 GB repo cache quota ## Context Measured on run [30364148082](https://github.com/ComposioHQ/composio/actions/runs/30364148082) (PR run, ~90s wall time): | Step | Time | |---|---| | Checkout | 5s | | Setup Node.js, pnpm, Bun | 34s (mise 1s, setup-node 5s, setup-bun 2s, pnpm 2s, **pnpm store restore 18s** for 658 MB, turbo restore 1s) | | `pnpm install --frozen-lockfile` | 14s | | `pnpm lint` | 1s | | `pnpm run build:packages` | 24s, **0/19 turbo cache hits** | | Post-job cache saves | ~11s (turbo save + a 658 MB pnpm store save that failed with "Unable to reserve cache", racing the parallel ts.* jobs on the same PR) | The build restored a turbo cache only via the fallback restore-key `Linux-turbo-build-` from an unrelated branch, hence 0 hits. Once push runs fire on `next` again, every merge saves a fresh `Linux-turbo-build-<sha>` cache that PR runs match through the restore-key prefix, so unchanged packages become turbo hits (up to ~20s off the build step) and the ~11s post-job save disappears from PR runs. The per-commit key suffix is kept intentionally: the turbo cache accumulates, so each default-branch save needs a fresh key and readers match via the prefix (documented inline in the action).