pnpm defaults to frozen-lockfile in CI. The committed lockfile
is outdated (vitest added to package.json). Using --no-frozen-lockfile
is a pragmatic fix; lockfile should be regenerated via 'pnpm install'
and recommitted for full --frozen-lockfile enforcement.
Iteration 1 — CI reliability and speed:
- Concurrency: cancel in-progress CI runs when new push arrives
to the same branch. Why: Avoids waste when pushing multiple
fixes in quick succession; only the latest code is tested.
- pnpm: switch from --no-frozen-lockfile to --frozen-lockfile.
Why: Fails fast if pnpm-lock.yaml is outdated — prevents
untested dependency changes from reaching main.
- pnpm: add --prefer-offline to use locally cached packages.
Why: Slightly faster installs when packages are already
available in the runner image cache.
Iteration 1 — Build caching:
- Backend: cache ~/.nuget/packages keyed on .csproj hashes.
Typical hit: restore drops from ~15s to ~2s (NuGet packages
already cached locally).
- Frontend: cache node_modules + ~/.pnpm-store keyed on
pnpm-lock.yaml. Typical hit: install drops from ~30s to ~3s.
- Concurrency: cancel in-progress CI runs when new push arrives
to the same branch (avoids queue buildup).
Why: On cache hits, CI time drops ~60-70%. Faster feedback for
developers means shorter fix-deploy cycles.
reviewer
devops
bao