ci: rebuild Pages order from full LLGo history

[zhouguangyuan0718]

Summary

• unshallow the LLGo checkout before assigning first-parent main indices
• let the Pages-only workflow fetch complete LLGo main history and reindex all stored runs
• cover replacement of stale duplicate llgoMainIndex values in the ordering test

Validation

• bash -n ci/llgo-size/publish-site.sh ci/llgo-size/publish.sh
• python3 -m unittest ci/llgo-size/test_enrich_pull_requests.py
• Ruby YAML parse for both changed workflows
• fetched the real 1540-commit LLGo first-parent history and reindexed the current Pages index; latest entries became 8b630ab5 (1540), fd3b2873 (1539), then older commits

[fennoai]

Review: reindex Pages from full LLGo main history

The core idea is sound and well-executed: rebuild each run's first-parent main position from an authoritative full history rather than trusting the index embedded at build time. The --filter=blob:none --no-checkout --single-branch clone in the Pages workflow is an efficient, correct choice for a commit-graph-only consumer, and --unshallow in the benchmark workflow is a necessary correctness fix (a bounded, blob-free cost). The added inline comments accurately describe the behavior they motivate, load_main_history validates commit format and fails loudly, and --main-history stays optional so ordering gracefully falls back to embedded hints.

One inline finding on the test. A few minor notes below.

Minor / non-blocking

• order_runs never clears a stale llgoMainIndex for commits absent from the rebuilt history (ci/llgo-size/enrich_pull_requests.py). The reindex only sets the index for commits found in main_history; a run whose commit is no longer on first-parent main (rebase/force-push/dropped commit) keeps its embedded index from report.sh/publish.sh and is still treated as a main run by is_main_run, sorting into the topological section with a bogus position. Since the PR's premise is that the embedded index is "only a hint," consider clearing it when a real history is supplied: elif main_history: run.pop("llgoMainIndex", None) — guarded so the no---main-history path still preserves hints.
• Security context (pre-existing, out of this diff's scope): the Pages workflow sources ci/llgo-size/llgo-version.env and interpolates ${LLGO_REPOSITORY} into a clone URL. Here it's low risk (the Pages job runs only from main/workflow_dispatch with trusted content). Note that llgo-binary-size.yml uses the same source pattern on the pull_request build path, where PR-controlled content is executed on the runner and LLGO_REPOSITORY is unvalidated before the clone — no secret/write-token exposure (it's pull_request, not pull_request_target, and publish steps are main-gated), but arbitrary runner code execution and cloning from an attacker-chosen repo are possible. Worth hardening separately by parsing/validating instead of sourceing.
• Optional wording nit: the comment "otherwise every run appears to be main index 1" (llgo-binary-size.yml) describes the shallow symptom; "runs can collapse to main index 1" is slightly more precise.

[fennoai]

[P2] Test presets are dead input; doesn't verify stale-index correction

Both runs now carry llgoMainIndex: 1, but both commits (first, second) are in the main_history passed to order_runs, which unconditionally overwrites the index for any in-history commit. The preset 1 values are therefore always overwritten to 1/2, and the test passes identically whether they are 1,1 or absent — so it does not actually exercise replacement of a stale index, despite the test name.

If the intent is to prove a stale index gets corrected, make the presets wrong (e.g. both 99) and assert the corrected [2, 1]. Otherwise these two added lines add no coverage and could be reverted.