githubnext / githubnext/gh-aw-cao
[self-care:docs-build-time-investigator] Skip scheduled dashboard rebuilds when a same-revision bundle is already reusable
- Dominant language
- JavaScript
- Stars
- 3
- Forks
- 1
- Avg merge
- 49m
- Merged PRs (30d)
- 837
Description
### Summary
The scheduled Documentation Pages workflow is repeatedly paying dashboard-build dispatch and child workflow time even when all observed cacheable inputs are already reused. In 5 comparable successful scheduled runs from 2026-09-10T16:45:43Z to 2026-09-10T17:45:51Z, docs.yml spent a 25s median in `dashboard` → `Dispatch dashboard build`, while the dispatched `dashboard-build.yml` child still added 18s median execution to rebuild and hand off the dashboard bundle. The dashboard content work itself was tiny: child `Build Dashboard Language sources` stayed at 1s median and cached activity restore stayed at 1s median. This makes the current always-dispatch path the largest repeatable build-time cost in the sampled scheduled runs.
### Timing evidence
- Evidence window: 2026-09-10T16:45:43Z to 2026-09-10T17:45:51Z
- Sample: 5 comparable successful `docs.yml` scheduled runs and their matching dispatched `dashboard-build.yml` runs
- Comparable runs: `34504070699`, `34505667727`, `34507660767`, `34508687201`, `34510193706`
- Parent workflow queue time: median 0s, p90 0s
- Parent workflow execution time: median 82s, p90 109.6s
- Parent job durations:
- `dashboard`: median 31s, p90 33.2s
- `build`: median 27s, p90 34.6s
- `deploy`: median 9s, p90 9.6s
- Repeated step costs in `docs.yml`:
- `dashboard` → `Dispatch dashboard build`: median 25s, p90 27.2s
- `build` → `Set up Node.js`: median 4s, p90 6.2s
- `build` → `Restore node_modules`: median 6s, p90 7.2s
- `build` → `Build documentation`: median 7s, p90 8s
- `build` → `Restore dashboard from cache`: median 0s, p90 1s
- `build` → `Mount dashboard at /cao`: median 2s, p90 2s
- `build` → `Upload Pages artifact`: median 3s, p90 3s
- Dispatched `dashboard-build.yml` execution:
- child workflow execution: median 18s, p90 22s
- `Restore collected activity data`: median 1s, p90 1.6s
- `Build Dashboard Language sources`: median 1s, p90 1s
- `Cache dashboard artifact for the dispatching workflow`: median 1s, p90 1.6s
- `Upload dashboard data artifact`: median 1s, p90 2.6s
- `Upload dashboard artifact`: median 3s, p90 3s
- Failed/outlier disclosure: recent completed docs workflow runs also included failed non-comparable push and one failed schedule run, which were excluded from the timing sample rather than treated as normal.
- Confidence: medium-high for the repeated scheduled path because all 5 sampled runs showed the same pattern across both parent and child workflows.
### Bottleneck
`docs.yml` always dispatches `dashboard-build.yml` in the `dashboard` job and waits for it before the main build proceeds. In the sampled scheduled runs, trusted step metadata showed dependency installation was already avoided on every parent run (`Install dependencies` and `Save node_modules` were skipped every time), and trusted child metadata showed cached activity data was restored successfully in every child run. Yet the workflow still incurred a median 43s of combined parent wait plus child execution to produce and hand off a dashboard bundle whose actual source-generation step took only 1s median.
Relevant source locations:
- `.github/workflows/docs.yml`: `dashboard` job dispatches `dashboard-build.yml`, then `build` restores/downloads the child artifact with a run-specific cache key.
- `.github/workflows/dashboard-build.yml`: child workflow restores cached activity data, rebuilds dashboard sources, saves the dashboard cache, and uploads artifacts on every dispatch.
### Recommended changes
1. In `.github/workflows/docs.yml`, add a same-revision reusable dashboard shortcut before dispatching `dashboard-build.yml` for scheduled/cache-mode runs.
2. Key that reusable dashboard bundle by the source revision that controls the dashboard output, such as `github.workflow_sha` plus any other dashboard-content inputs that materially affect correctness.
3. Attempt to restore that persistent bundle first in the parent workflow; only dispatch `dashboard-build.yml` when the reusable bundle is missing, stale, or when a live/fresh rebuild is explicitly required.
4. Keep the current dispatched child path as the correctness-preserving fallback so cache misses and live refresh cases still rebuild and republish the dashboard safely.
A concrete shape would be:
- parent `actions/cache/restore` (or equivalent existing safe reusable bundle mechanism) keyed by dashboard-producing revision and mode
- conditional skip of the `dashboard` dispatch job when the reusable bundle is restored
- parent `build` mounts the restored bundle directly instead of waiting for a child run
- fallback continues using the current child-run artifact/cache handoff when the restore misses
### Expected effect and validation
- Expected effect: avoid roughly 43s median of repeated scheduled-run work (25s median parent dispatch wait + 18s median child execution), which is about 52% of the sampled 82s median parent workflow execution time.
- This exceeds the required 60s-or-15% threshold by percentage, even though not by absolute seconds.
- Validation check:
1. compare at least five scheduled runs before and after the change;
2. confirm parent workflow median execution drops materially;
3. confirm `dashboard-build.yml` is skipped on cache-hit schedule runs;
4. confirm dashboard content matches the current source revision and live/fallback runs still rebuild correctly when inputs change.
### Caveats
- The reusable key must include every input that changes dashboard correctness; otherwise the shortcut risks serving stale dashboard output.
- This recommendation is limited to scheduled/cache-mode runs. Push-triggered docs builds may still need the current fallback depending on freshness guarantees and changed inputs.
- Duplicate open-issue verification could not be completed in this environment because `gh issue list` exited non-zero, so maintainers should quickly confirm there is no already-open equivalent issue before acting.
### Control Plane
- Correlation ID: `34510093641-535`
- Central repository: `githubnext/gh-aw-cao`
- Control plane run: https://github.com/githubnext/gh-aw-cao/actions/runs/34510093641
### References
- `docs.yml` runs:
- https://github.com/githubnext/gh-aw-cao/actions/runs/34504070699
- https://github.com/githubnext/gh-aw-cao/actions/runs/34505667727
- https://github.com/githubnext/gh-aw-cao/actions/runs/34507660767
- https://github.com/githubnext/gh-aw-cao/actions/runs/34508687201
- https://github.com/githubnext/gh-aw-cao/actions/runs/34510193706
- `dashboard-build.yml` runs:
- https://github.com/githubnext/gh-aw-cao/actions/runs/34504085819
- https://github.com/githubnext/gh-aw-cao/actions/runs/34505684245
- https://github.com/githubnext/gh-aw-cao/actions/runs/34507681220
- https://github.com/githubnext/gh-aw-cao/actions/runs/34508767153
- https://github.com/githubnext/gh-aw-cao/actions/runs/34510207463
- Workflow sources:
- `.github/workflows/docs.yml`
- `.github/workflows/dashboard-build.yml`
> Generated by [SelfCare / Docs Build Time](https://github.com/githubnext/gh-aw-cao/actions/runs/34510632619) · pi · gpt54 · 38.4 AIC · ⌖ 7.2 AIC · ⊞ 8.8K · [◷](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 24, 2026, 5:57 PM UTC
Contributor guide
Research direction
Read .github/workflows/docs.yml and .github/workflows/dashboard-build.yml, focusing on the dashboard dispatch, cache keys, and artifact handoff. Compare the existing scheduled/cache-mode path with the proposed same-revision restore and fallback conditions. Done means cache-hit scheduled runs skip dashboard-build.yml, the bundle matches all relevant revision inputs, and live or cache-miss runs still rebuild correctly; validate across at least five scheduled runs.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions
- Domain
- ci-cd, performance
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100