Use shallow fetches for generated dashboard branches

[jamesmontemagno]

Problem

The dashboard publishing workflow fetches and clones generated branches that contain append-only snapshots. Its consumers only need the current files at each branch tip, but several operations currently allow Git to bring in the branches' full reachable ancestry. On ephemeral Actions runners, that creates avoidable network transfer and object retention.

This is not the same as the repository's compact server-side size. GitHub repository metadata reports roughly 139,194 KiB (~136 MiB) because the server-side pack is well delta-compressed. Our local analysis with git-sizer, however, found about 10.2 GiB of total uncompressed blob content across reachable history.

Evidence

Measurements from a fresh bare clone show how much historical snapshot content is reachable from each generated branch versus how compactly GitHub can represent it in an optimized pack:

Generated branch	Raw historical blob content	Blob count	Optimized on-disk representation
gh-pages	~4,187.8 MiB	3,026	~94.4 MiB
dashboard-eval-data	~1,970.6 MiB	1,966	~47.4 MiB
dashboard-token-data	~7,582.0 MiB	624	~67.3 MiB

These branch totals overlap because branches can reach shared objects. They should not be added together and presented as the repository's unique size.

One concrete source of growth is data/token-usage.json: the analysis found 258 historical gh-pages versions, with individual historical blobs reaching roughly 20–40 MiB. That history is useful context for understanding object volume, but the workflow reads only the current file.

Why this happens

The generated branches are append-only snapshots. Fetching a disconnected generated branch without --depth=1 can download and retain ancestry that the job never reads. Depending on fetch order, automatic maintenance/repacking, retained refs or reflogs, and duplicate or poorly packed local packs, an ephemeral runner can therefore end up with much more data than GitHub's optimized server-side pack suggests.

This explains reports of workflow .git directories exceeding 2 GiB without implying that every clone will have that size. The exact local footprint is sequence- and maintenance-dependent.

What changed

This PR adds --depth=1 at all seven relevant sites in .github/workflows/evaluation.yml:

• four fetches: dashboard-token-data and dashboard-eval-data in their data-generation jobs, plus both branches again in deploy-dashboard
• three clones: dashboard-token-data, dashboard-eval-data, and gh-pages before publishing updates

No unrelated fetches or clones are changed.

Safety and behavior

The change preserves the existing workflow behavior:

• data consumers use checkout, show, or copy only against files in the fetched tip snapshot; they do not inspect generated-branch history
• publishers shallow-clone the current tip, update the snapshot, and create a normal child commit, so the push remains a fast-forward update
• existing error handling and branch-creation paths are unchanged

Limitations

This is deliberately a safe first step. It does not rewrite or compact existing remote history, alter retention behavior, force-push, or permanently stop generated-branch history growth. It reduces runner transfer and local object retention now.

A maintainer-approved generated-branch compaction or migration to Pages artifacts could address remote history growth separately, but neither is part of this PR.

Validation

• actionlint v1.7.7 passed for .github/workflows/evaluation.yml with ShellCheck and pyflakes integration disabled, matching the repository's targeted workflow validation.

[github-actions]

Note

This PR is from a fork and modifies infrastructure files (eng/ or .github/).

Changes to infrastructure typically need to be submitted from a branch in dotnet/skills (not a fork) so that CI workflows run with the correct permissions and secrets.

Please consider recreating this PR from an upstream branch. If you don't have push access to dotnet/skills, ask a maintainer to push your branch for you.

[Copilot]

Copilot review overview

🟢 Approval recommended

Review tier: Lite
Findings: None

What changed in this PR

This PR reduces GitHub Actions network/disk usage by switching generated dashboard snapshot branches (dashboard-token-data, dashboard-eval-data, and gh-pages) to shallow fetch/clone operations where only the current tip is consumed or updated.

Changes:

• Use git fetch --depth=1 when retrieving the latest snapshot content from dashboard-token-data and dashboard-eval-data.
• Use git clone --depth=1 when preparing working copies of dashboard-token-data, dashboard-eval-data, and gh-pages for publishing updates.

File	Description
.github/​workflows/​evaluation.yml	Updates fetch/clone commands for generated dashboard branches to use depth-1 shallow operations while preserving existing publish behavior.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

🔒 Secret-backed evaluation is disabled for fork PRs. A maintainer must review and promote the change to a trusted repository branch before running /evaluate. View workflow run

[AbhitejJohn]

Thanks for the fix James. If you wouldn't mind converting this to a branch in the repo, the CI should kick in and we can merge this through.

[jamesmontemagno]

@AbhitejJohn I confirmed my account has triage/pull access but not push access to dotnet/skills, so I cannot create the trusted branch myself. The approved change is commit 087ac1445817a552f26b5f1c64f52491f3c933ca on jamesmontemagno/skills:motz-shallow-dashboard-fetches.

A maintainer can promote it with:

git fetch https://github.com/jamesmontemagno/skills.git motz-shallow-dashboard-fetches
git push origin FETCH_HEAD:refs/heads/motz-shallow-dashboard-fetches

GitHub cannot change an existing PR's head repository, so after the upstream branch exists we should open a replacement PR from dotnet:motz-shallow-dashboard-fetches, then close this fork PR. I am leaving this open until the replacement exists so the approved commit and discussion remain easy to find.

[AbhitejJohn]

@jamesmontemagno : Sounds good. I ported this over here: #1099. Thanks again for the fix.