githubnext / githubnext/gh-aw-cao
[self-care:docs-build-time-investigator] Inline dashboard generation into docs.yml to remove cross-workflow artifact churn
- Dominant language
- JavaScript
- Stars
- 3
- Forks
- 1
- Avg merge
- 49m
- Merged PRs (30d)
- 837
Description
### Summary
The current Documentation Pages workflow spends most of its median runtime moving an already-built dashboard between workflows instead of generating content. Across 10 comparable successful scheduled runs in the last 5 hours, the full `docs.yml` workflow median was 93s (p90 98s). A single workflow change—building the dashboard inline in `docs.yml` and uploading one final Pages artifact—should remove the dispatch/cache/artifact handoff and is the only observed bottleneck category in this cycle that plausibly clears the 60s or 15% threshold.
### Timing evidence
Evidence window: 2026-09-07 05:33Z to 09:34Z. Sample: 10 successful scheduled `docs.yml` runs and their paired `dashboard-build.yml` runs; 2 failed scheduled `docs.yml` runs (34088046244, 34103781863) were excluded from timing baselines and are disclosed here as non-comparable failures.
For `docs.yml` successful scheduled runs:
- Workflow total median 93s, p90 98s.
- Queue-to-first-job-start median 3s, p90 3s.
- `dashboard` job median 43s, p90 47s.
- `build` job median 29s, p90 31s.
- `deploy` job median 9.5s, p90 11s.
For paired `dashboard-build.yml` runs:
- Workflow total median 35.5s, p90 37s.
- `activity` job median 5.5s, p90 7s.
- `build` job median 21s, p90 21s.
- `build` queue delay median 14s before any dashboard work starts.
Repeated step costs from trusted job metadata and logs:
- `docs.yml` build job `Restore dashboard from cache` always missed because the key is run-specific (`cao-dashboard-${run-id}-${attempt}`), so all 4 inspected logs fell back to artifact download.
- `dashboard-build.yml` build job `Restore collected activity data` repeatedly downloaded and extracted a ~99 MB cache; logs show 103,643,606 to 103,668,906 bytes restored.
- `dashboard-build.yml` uploaded two more artifacts every run: `central-agentic-ops-dashboard-data` at ~7.69 MB and `central-agentic-ops-dashboard` at ~8.06 MB.
- `docs.yml` then downloaded the dashboard artifact and repackaged the final Pages artifact at ~9.0 MB.
Relevant runs:
- `docs.yml`: 34106603276, 34102833839, 34101356307, 34098492499, 34097489761, 34096056735, 34094111646, 34092379983, 34089158741, 34087277027
- Paired `dashboard-build.yml`: 34106614861, 34102845354, 34101368235, 34098503762, 34097500370, 34096070618, 34094122022, 34092391756, 34089166262, 34087284284
Confidence: medium. The evidence is consistent across 10 like-for-like scheduled runs on multiple source SHAs, but the sample window is short and limited to currently fast cache-backed runs.
### Bottleneck
The bottleneck is cross-workflow handoff, not page rendering.
`dashboard-build.yml` already finishes dashboard assembly quickly once its activity cache is restored: `Assemble Dashboard Language site` median 1s and `Build Dashboard Language sources` median 1.5s. The heavier repeated cost is orchestration overhead:
- a second workflow dispatch and queue delay,
- restoring the large activity cache in the reusable workflow,
- saving a run-scoped dashboard cache that `docs.yml` cannot hit in the same run history,
- uploading dashboard artifacts there,
- downloading them back in `docs.yml`, and
- uploading a final Pages artifact again.
This indirection dominates the 43s median `dashboard` job and a material portion of the 29s `build` job even though the actual dashboard generation work is only a few seconds.
### Recommended changes
1. Collapse the dashboard handoff into `docs.yml` by running the dashboard build steps directly in the `build` job after `npm run docs:build`, reusing the existing checked-out source.
2. Keep activity snapshot reuse, but restore the activity cache directly in `docs.yml` instead of dispatching `dashboard-build.yml` just to restore and re-upload dashboard output.
3. Remove from `docs.yml` the run-scoped `Restore dashboard from cache` and `download-artifact` path, since the producer and consumer would be the same job or same workflow.
4. Emit only the final Pages artifact once.
Source locations to update:
- `.github/workflows/docs.yml`
- `.github/workflows/dashboard-build.yml` (either retire this path for Pages publishing or narrow it to standalone dashboard use only)
### Expected effect and validation
Expected effect: save roughly 20–35 seconds per scheduled `docs.yml` run from eliminating the second workflow’s queue/startup plus dashboard artifact save/download churn. That is about 22%–38% of the current 93s median workflow time. If activity restoration can also be shared more directly inside one workflow, savings could trend higher, but the estimate above only credits overhead clearly observed in current logs.
Validation:
1. Compare at least 5 post-change successful scheduled runs against this baseline.
2. Check that median workflow time drops below 75s and p90 below 85s without increased failure rate.
3. Confirm from logs that there is no separate `dashboard-build.yml` dispatch for normal Pages publishes and no dashboard artifact round-trip before Pages upload.
4. Confirm site output freshness matches the current `cache` mode behavior.
### Caveats
- This recommendation does not weaken freshness or deployment safety only if the inline job preserves the current trusted-source checkout and activity-data validation gates.
- It assumes the dashboard remains needed only for Pages output during routine `docs.yml` runs. If `dashboard-build.yml` serves other consumers, keep it for those paths and split the Pages path from the reusable artifact-production path.
- Open-issue duplicate checking was partially limited by a transient `gh issue list` GraphQL 502 response, so deduplication confidence is lower than normal.
### Control Plane
- Correlation ID: 34106205146-335
- Central repository: githubnext/gh-aw-cao
- Control plane run: https://github.com/githubnext/gh-aw-cao/actions/runs/34106205146
### References
- Workflow source: `.github/workflows/docs.yml`
- Workflow source: `.github/workflows/dashboard-build.yml`
- Run: https://github.com/githubnext/gh-aw-cao/actions/runs/34106603276
- Run: https://github.com/githubnext/gh-aw-cao/actions/runs/34102833839
- Run: https://github.com/githubnext/gh-aw-cao/actions/runs/34101356307
- Run: https://github.com/githubnext/gh-aw-cao/actions/runs/34098492499
- Run: https://github.com/githubnext/gh-aw-cao/actions/runs/34097489761
> Generated by [SelfCare / Docs Build Time](https://github.com/githubnext/gh-aw-cao/actions/runs/34106581937) · pi · gpt54 · 50.5 AIC · ⌖ 8.54 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 21, 2026, 9:42 AM UTC
Contributor guide
Research direction
Start by reading .github/workflows/docs.yml and .github/workflows/dashboard-build.yml, then inspect the listed successful runs and logs to map the current dispatch, cache, artifact, and validation gates. Done means normal Pages publishes build the dashboard inline, avoid the dashboard artifact round-trip and separate dispatch, preserve freshness and trusted-source checks, and meet the stated runtime and failure-rate validation targets.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions
- Domain
- ci-cd, documentation
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 48/100