githubnext / githubnext/gh-aw-cao

[self-care:docs-build-time-investigator] Reduce docs Pages p90 by avoiding repeated cold npm installs

Open
#910 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
JavaScript
Stars
3
Forks
1
Avg merge
48m
Merged PRs (30d)
853

Description

### Summary
The docs Pages workflow is usually fast once dependencies are warm, but `npm ci` is still the dominant repeated cost in the `build` job and occasionally collapses the whole workflow SLO when the cache misses. Across 12 successful `docs.yml` runs in the last ~2.5 hours, median full-workflow time was 95.5s and p90 was 213s; the `build` job median was 31s but p90 rose to 66s because one otherwise comparable scheduled run spent 302s in `Install dependencies` alone. The best evidence-backed improvement is to harden Node dependency reuse for `.github/workflows/docs.yml` so a single npm cache miss does not add ~4–5 minutes to docs publishing.

### Timing evidence
- Evidence window: 2026-09-03T20:22:25Z through 2026-09-03T22:28:04Z.
- Successful comparable samples analyzed: 12 completed `docs.yml` runs; 9 schedule-triggered and 3 push-triggered. Cancelled runs were excluded. One scheduled outlier was retained and disclosed.
- Like-for-like subset: 5 successful scheduled runs at source SHA `95bf9bd3bc8b8e7c150d8849e63e1330891364ec`.
- Full workflow duration (`docs.yml`): median 95.5s, p90 213s.
- `dashboard` job execution: median 36.5s, p90 47s.
- `build` job execution: median 31s, p90 66s.
- `deploy` job execution: median 9.5s, p90 11s.
- Queue time is not the main bottleneck in typical runs: median queue to `dashboard` start 5s, to `build` start 46.5s, to `deploy` start 86s. The large p90 full-workflow value mainly came from execution inflation, not just waiting.
- Step timings inside `build` show the repeated hotspot:
- `Install dependencies`: usually 8–9s, one run at 41s, one run at 302s.
- `Build documentation`: 3–5s.
- `Mount dashboard at /cao`: 0–2s.
- `Upload Pages artifact`: 1–3s.
- The worst outlier was run `33812676843`, where `Install dependencies` took 302s while `Build documentation` still took only 4s and deployment remained normal.

### Bottleneck
`actions/setup-node` with `cache: npm` is helping only when the npm package tarball cache is already warm; it does not avoid `npm ci`, and the logs/step timings show that dependency installation still dominates the `build` job whenever the cache is cold or invalidated. In `.github/workflows/docs.yml`, the `build` job does all of the following before a docs build that itself takes only a few seconds:
- sets up Node with npm cache support;
- runs `npm ci` against the repository root;
- runs `npm run docs:build`;
- downloads the dashboard artifact and uploads the Pages artifact.

By contrast, the reusable dashboard generation path in `.github/workflows/dashboard-build.yml` is already short: median dashboard-build workflow time for matched dispatches was about 24–29s total, and its own build steps were mostly 0–2s each because it restores pre-collected activity data and only assembles/upload artifacts. The bottleneck for this category is therefore dependency reuse in the docs `build` job, not Astro generation or artifact transfer.

### Recommended changes
1. Strengthen dependency reuse in `.github/workflows/docs.yml` so the Pages build can skip a full root-level reinstall on unchanged lockfiles.
- Preferred approach: add a dedicated dependency-priming job keyed by `package-lock.json` that restores or creates a reusable dependency bundle for the exact lockfile, then let the `build` job consume that bundle instead of running `npm ci` from scratch every run.
- Concretely, this can be done with a lockfile-keyed artifact or cache of the installed dependency tree used only within the workflow’s trusted branch context, followed by a fast integrity check before `npm run docs:build`.
2. If keeping a single-job design, broaden cache resilience beyond the current npm tarball cache.
- `actions/setup-node` with `cache: npm` only caches downloaded packages, not the installed tree. Add an explicit restore/save cache for the installed dependency output keyed by OS + Node version + `hashFiles('package-lock.json')`, or otherwise restructure so docs build consumes a prebuilt dependency artifact.
3. Validate with a short before/after sample on scheduled runs at the same SHA.
- Success criteria: `Install dependencies` no longer exceeds ~10–20s on warm runs and p90 full-workflow time drops by at least 60s.

### Expected effect and validation
- Expected effect: removing the cold-install path would save roughly 4–5 minutes on the observed miss outlier and should reduce p90 full-workflow duration from 213s toward the non-outlier cluster near 81–101s.
- Conservative estimate: at least 60s p90 improvement, and about 15%+ improvement versus the current 95.5s median in cases where lockfile-stable scheduled runs currently rehydrate dependencies inefficiently.
- Confidence: medium.
- High confidence that `npm ci` is the dominant repeated cost because step timings show it clearly.
- Medium confidence on exact savings frequency because only one severe miss appeared in the sampled window, but it was within an otherwise comparable scheduled run at the same source SHA.
- Validation plan:
1. Compare at least five scheduled runs before and after the change on identical or near-identical lockfiles.
2. Track `Install dependencies`, total `build` execution, and full workflow duration.
3. Confirm no correctness regressions by diffing generated docs output size/hash and ensuring Pages deployment still succeeds.

### Caveats
- This recommendation is intentionally limited to the current suggestion category: dependency installation and caching.
- Queue delays still contribute to end-to-end time, but changing dependency reuse is the only evidence-backed workflow change in this category that meets the required savings threshold without weakening safety or freshness.
- The outlier could reflect transient registry/network slowness, but the workflow can still be made more resilient to that class of delay by reducing reliance on repeated cold installs.
- I did not recommend skipping builds on push or schedule because that belongs to the later scheduling/avoidable-rebuild category.

### Control Plane
- Correlation ID: `33813207193-125`
- Central repository: `githubnext/gh-aw-cao`
- Control plane run: https://github.com/githubnext/gh-aw-cao/actions/runs/33813207193

### References
- Workflow source: `.github/workflows/docs.yml`
- Reusable workflow source: `.github/workflows/dashboard-build.yml`
- Sample docs runs:
- https://github.com/githubnext/gh-aw-cao/actions/runs/33812676843
- https://github.com/githubnext/gh-aw-cao/actions/runs/33811026112
- https://github.com/githubnext/gh-aw-cao/actions/runs/33809699152
- https://github.com/githubnext/gh-aw-cao/actions/runs/33808371432
- https://github.com/githubnext/gh-aw-cao/actions/runs/33807479311
- https://github.com/githubnext/gh-aw-cao/actions/runs/33805671222
- Matched dashboard-build runs:
- https://github.com/githubnext/gh-aw-cao/actions/runs/33812688684
- https://github.com/githubnext/gh-aw-cao/actions/runs/33811047481

> Generated by [SelfCare / Docs Build Time](https://github.com/githubnext/gh-aw-cao/actions/runs/33813525233) · pi · gpt54 · 37.9 AIC · ⌖ 8.49 AIC · ⊞ 8.5K · [◷](https://github.com/search?q=repo%3Agithubnext%2Fgh-aw-cao+is%3Aissue+%22gh-aw-workflow-call-id%3A+githubnext%2Fgh-aw-cao%2Fself-care-docs-build-time-investigator%22&type=issues)
> - [x] expires on Sep 17, 2026, 10:39 PM UTC

Contributor guide

Open the contributing guide

Research direction

Read .github/workflows/docs.yml, especially the build job's setup-node, npm ci, and docs:build steps; compare it with .github/workflows/dashboard-build.yml. Use the cited scheduled runs as a baseline, then validate at least five comparable runs, confirming generated docs output and Pages deployment while install time stays near 10–20 seconds and p90 improves by at least 60 seconds.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions, javascript, node.js
Domain
ci-cd, devops, performance
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.