Skip to content

feat(ci): cache npm tarballs and supersede in-flight PR runs - #68

Merged
laurenhitchon merged 1 commit into
mainfrom
feat/ci-cache-and-concurrency
Jul 30, 2026
Merged

feat(ci): cache npm tarballs and supersede in-flight PR runs#68
laurenhitchon merged 1 commit into
mainfrom
feat/ci-cache-and-concurrency

Conversation

@laurenhitchon

Copy link
Copy Markdown
Contributor

Minutes-reduction batch (amended version of the caching plan drafted 2026-07-29).

npm cachingcache: 'npm' + cache-dependency-path: package-lock.json on all 8 setup-node steps in reusable-ci. Caches ~/.npm only: npm clean-install still wipes node_modules and validates every package against the lockfile's integrity hashes, so the lockfile-integrity gate is untouched — the cache only changes where tarballs come from. All 25 repos have lockfiles (verified fleet-wide), so the setup-node lockfile requirement introduces no new failure mode. Lockfile-bump PRs (Renovate weekly / lockfile maintenance) are cold by definition. reusable-release deliberately stays uncached — pristine publish path (policy now documented in the header).

Concurrency — the ci.yml stub gains concurrency: ci-${{ github.ref }} with cancel-in-progress: true: rapid successive pushes to a PR supersede in-flight runs instead of running duplicate 4-job CI to completion (review finding L-18). Lives in the stub because workflow-level concurrency in a called workflow is not applied. Fans out via sync.

Rollout: merge → sync wave → canary on a nswds-email draft PR run twice (expect a "Cache restored from key" log + shorter install on run 2, and run 1 cancelled by run 2's push) → promote v1 via the Promote v1 workflow.

- cache: npm + cache-dependency-path on all 8 setup-node steps in
  reusable-ci — restores ~/.npm keyed on the lockfile hash; npm ci still
  wipes node_modules and verifies lockfile integrity hashes, so the
  merge-gate guarantee is unchanged. Release path stays uncached.
- concurrency group in the ci.yml stub: rapid successive pushes cancel
  superseded runs instead of burning 4 duplicate jobs to completion.
Copilot AI review requested due to automatic review settings July 30, 2026 02:27
@DFSIdigital

DFSIdigital commented Jul 30, 2026

Copy link
Copy Markdown

Snyk checks have passed. No issues have been found so far.

Status Scan Engine Critical High Medium Low Total (0)
Open Source Security 0 0 0 0 0 issues
Licenses 0 0 0 0 0 issues
Code Security 0 0 0 0 0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

@laurenhitchon
laurenhitchon merged commit ca99c2c into main Jul 30, 2026
10 checks passed
@laurenhitchon
laurenhitchon deleted the feat/ci-cache-and-concurrency branch July 30, 2026 02:28

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR optimizes CI runtime across the fleet by enabling npm tarball caching in the reusable CI workflow and by adding workflow-level concurrency to CI stubs so new pushes supersede in-flight PR runs.

Changes:

  • Add concurrency to the ci.yml workflow stub to cancel in-progress CI runs on rapid successive PR pushes.
  • Enable actions/setup-node npm caching (keyed by package-lock.json) across all Node setup steps in reusable-ci.yml.
  • Document caching policy in the reusable CI workflow header (including the explicit non-cached release workflow policy).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File Description
workflow-stubs/ci.yml Adds workflow-level concurrency so newer PR pushes cancel older in-flight CI runs.
.github/workflows/reusable-ci.yml Enables npm cache usage on all setup-node steps and documents the caching policy.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread workflow-stubs/ci.yml
Comment on lines 19 to 20
permissions:
contents: read
Comment on lines +4 to +8
# Caching policy: every setup-node step caches ~/.npm keyed on the lockfile
# hash. This only changes where npm ci fetches tarballs from — node_modules
# is still wiped and rebuilt, and npm ci still verifies every package
# against the lockfile's integrity hashes, so the lockfile-integrity
# guarantee this workflow exists for is untouched. Lockfile-bump PRs are
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants