Speed up staging with one targeted partial checkout - #894
LukasWallrich wants to merge 3 commits into
Conversation
|
👍 All image files/references (if any) are in webp format, in line with our policy. |
✅ Spell Check PassedNo spelling issues found when checking 3 changed file(s)! 🎉 |
|
✅ Staging Deployment Status This PR has been successfully deployed to staging as part of an aggregated deployment. Deployed at: 2026-09-17 18:53:01 UTC The staging site shows the combined state of all compatible open PRs. |
|
just made a commit to fix the Conflicts vs. other merge failures which are now distinct I will check the rest later |
richarddushime
left a comment
richarddushime
left a comment
There was a problem hiding this comment.
A failed git fetch or gh pr view inside the merge loop aborts the whole aggregation under bash -e (verified: exit 128 at the first PR), so one deleted fork branch costs every other PR its staging preview — route fetch failures into the new failed bucket and continue.
gh pr list defaults to --limit 30, so a workflow documented as aggregating all open PRs silently stops doing so at 31 and says nothing in the log.
richarddushime
left a comment
richarddushime
left a comment
There was a problem hiding this comment.
Line 153 already requests title and discards it, then line 186 re-fetches it per PR via gh pr view for a single log line — an API round trip per PR and another set -e failure point, both removable by reading number+title from the list call (headRefName is dead now too).
PYTHON_VERSION: "3.11" at line 382 is consumed by nothing — there's no actions/setup-python in the job, so it reads as a pin that isn't one.
The unguarded --unshallow at line 110 is correct today but hard-fails on a complete repository, so a future fetch-depth: 0 here would break the workflow without pointing at the cause.
Lines 459 and 627 still use github.event.inputs.create_summary while the PR moved force_deploy and single_pr to the inputs.* context — both work, but the file is now inconsistent with itself.
pull-requests: read on the build job is unused, since every gh call in it authenticates with the PAT rather than GITHUB_TOKEN.
git checkout main at line 171 is redundant because Fetch main history already left HEAD on main and nothing in between changes branch.
2 participants
Description
Staging currently downloads the full history of every branch and tag twice. In run 35240766210, those checkouts took 3m 51s of a 6m workflow; Hugo took 43s.
Aggregate PRs and build Hugo in one checkout. Fetch only the full ancestry of
mainand selected PR refs, using a blobless partial clone so historical file contents are downloaded on demand. PR refs support both same-repository and fork previews. Preserve Git-derived page dates, conflict skipping, manual single-PR previews, force deployment, and scheduled reporting. Deployment requires a successfully uploaded site artifact. Keep the staging write token scoped to the aggregation step's Git pushes rather than persisting it into the build.Type of Change
Testing
Validation completed:
git diff --checkpasses.Checklist
Notes
A local cold checkout plus full
mainhistory took 55.4 seconds, with the history restoration taking under a second. These local timings are not directly comparable with GitHub-hosted runners; the PR's staging run will provide the hosted measurement. The existing queueing policy remains in place.@richarddushime could you review the workflow changes, particularly the combined job, partial fetching, and deployment conditions?