aws-samples / aws-samples/sample-autonomous-cloud-coding-agents
perf(ci): investigate yarn install --check-files (caches are cache-independent, not a hit-rate win) — follow-up to #363
- Dominant language
- TypeScript
- Stars
- 143
- Forks
- 46
- Avg merge
- 3d 9h
- Merged PRs (30d)
- 20
Description
Parent: #363 (build-performance umbrella). **needs maintainer `approved` before implementation (ADR-003)**.
> **⚠️ Corrected 2026-07-29 after measured re-review of PR #364 (@theagenticguy).** This issue was originally filed as "fix merge_group cache misses to save install time." **Measurement disproved that premise** — see below. The issue is retained but re-scoped to the *actual* question (do these caches earn their restore cost), and it is **no longer the lead lever**.
## Corrected finding
The `merge_group` cache misses (`node_modules=miss, venv=miss, jest=miss`) are **largely structural, not a misconfiguration**: per GitHub's cache docs, a cache created by a `pull_request` run is scoped to the merge ref (`refs/pull/.../merge`) and can only be restored by re-runs of that PR — merge-queue refs cannot read PR-branch caches.
More importantly, **fixing hit-rate saves ~zero**. Same `yarn.lock` hash, miss run `30412723686` vs hit run `30419878840`:
| | miss | hit |
|---|---|---|
| `Cache *` restore steps | 1s | **9s** |
| `yarn install --check-files` | 48.35s | 55.09s |
| `Install dependencies` step | 56s | 60s |
The cache-**hit** path is net **slower**. Cause: `mise.toml` `[tasks.install]` runs `yarn install --check-files`, which re-verifies every file and defeats a restored `node_modules`. `uv sync` on the miss run reported `Prepared 127 packages in 1.77s, Installed in 121ms`, so a venv cache costing ~3s to restore cannot pay for itself either.
## Re-scoped question (if pursued at all)
Install cost is **cache-independent** here. The real question is whether `yarn install --check-files` is necessary, and whether these caches earn their restore cost at all:
- Investigate dropping/replacing `--check-files` (measure correctness risk vs the ~48–55s it costs regardless of cache state).
- If caches don't earn their restore cost on either event, consider removing the cache steps rather than "fixing" them.
## Priority
**Not the lead lever.** The dominant addressable overhead is the `Free Disk Space` step (see the new issue and the re-ranked sequencing on #363). Sequence this *after* Free-Disk-Space, runner-bump (#677), and path-filters (#678). See `docs/design/CI_BUILD_PERFORMANCE.md` (corrected in PR #364).
Refs #363
Contributor guide
Research direction
Start with docs/design/CI_BUILD_PERFORMANCE.md and the [tasks.install] definition in mise.toml. Reproduce the miss and hit comparisons using the referenced runs, then evaluate whether yarn install --check-files is necessary and whether the venv and node_modules caches repay their restore cost. Done means a measured decision on replacing --check-files and retaining or removing the cache steps.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions
- Domain
- build-system, ci-cd, performance
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100