test(ci): GitCode upload network probe [THROWAWAY — do not merge] - #371
Closed
Sunrisepeak wants to merge 1 commit into
Closed
test(ci): GitCode upload network probe [THROWAWAY — do not merge]#371Sunrisepeak wants to merge 1 commit into
Sunrisepeak wants to merge 1 commit into
Conversation
Diagnoses whether a GitHub-hosted runner can upload a >8 MiB release asset to GitCode at all, and via which method (baseline gtc/urllib, curl default, curl --http1.1, curl --limit-rate 300k, curl --limit-rate 1M) against the real 27 MiB aarch64 asset. All other workflows are removed on this branch so this is the only PR check. Cleanup step best-effort deletes the throwaway probe release.
Member
Author
|
Probe complete — verdict: no upload method works from the GitHub-hosted runner. All 5 strategies (gtc/urllib, curl default, curl --http1.1, curl --limit-rate 300k/1M) timed out on the 27 MiB asset at a sustained ~15–31 KB/s (vs ~2.6 MB/s from a CN machine — ~100× slower). This is a saturated cross-border Azure-US→Huawei-Cloud-CN path, not a fixable script/protocol/rate issue. Throttling did not help; even --limit-rate 300k couldn't sustain 300k. No phantom assets were left; an empty |
Sunrisepeak
added a commit
that referenced
this pull request
Jul 14, 2026
…nbook (#372) * feat(mirror): mirror-latest wrapper + lazy source download for scheduled top-up Enables Plan A for the GitCode big-file gap (probe PR #371 proved GitHub runners cannot upload >8 MiB to GitCode): a CN machine with a healthy GitCode route runs this on a timer to top up whatever CI could not upload. - tools/mirror-latest.sh: resolve the latest published release (gh, or unauthenticated GitHub API fallback), load GITCODE_TOKEN from ~/.config/gitcode-tool/config.json when unset, exec mirror_res.sh. Safe for a non-interactive timer. - tools/mirror_res.sh: replace the eager 'download every asset up front' with expected sizes from ONE release-API call (no body download) + lazy ensure_local() that fetches an asset only when an upload needs it, with 3 retries (CN->GitHub is ~100 KB/s and a single give-up must not abort the whole run — that was the observed failure). Steady-state re-runs now move zero bytes. gh-side failures are collected/reported symmetrically with the gitcode side. Verified: syntax clean; live steady-state run against the fully-mirrored v0.4.65 skips all assets, downloads nothing. * fix(mirror): robust CN-side probing + public source fetch Follow-up hardening after live testing from a CN host: - WANT size-map parse used an f-string with escaped quotes that raised SyntaxError (swallowed by '|| true') -> map always empty -> every GitCode asset fell through to a false 'broken attachment' verdict and the GitHub block re-downloaded all ~48 MB. Use plain concatenation (matches the working 'registered' parse). - probe_ok(): retry cross-border GETs (3x, short cap) so a flaky runner/host probe is not misread as a missing/broken asset; used for the skip check and the final verify. - Source metadata + download now use the PUBLIC GitHub API / release URL (no gh auth) so a headless timer with a locked keyring still works. - gtc PUT socket timeout already 120s; probe cap 90s->60s. Verified from a CN host against the fully-mirrored v0.4.65: 16 skips, 0 downloads, all 16 URLs OK, 40s (was 12m with the empty-WANT bug). * docs(mirror): frame mirror-latest as the manual post-release GitCode top-up Per decision: no standing automation — the GitCode big-asset gap is filled by a maintainer running tools/mirror-latest.sh from any CN environment after a release (not tied to a personal machine, no timer). - tools/mirror-latest.sh: reframed header as THE manual post-release step; documents why it's manual (correctness already covered by the GitHub fallback; ~2-4 files/release) and where it must run. - tools/mirror_res.sh: stall + incomplete messages now point to running mirror-latest.sh from a CN environment. - release.yml / mirror-binaries.yml: annotate the known GitHub-runner GitCode big-asset limitation and the manual remediation. - .agents/docs/2026-07-15-gitcode-large-asset-mirror-runbook.md: single source of truth (measurements, rationale, exact procedure). * docs(runbook): record end-to-end validation (steady-state + gap-fill)
Sunrisepeak
added a commit
that referenced
this pull request
Aug 5, 2026
… to split it
The recommendation to make libLLVM its own package stood on two reasons that
do not survive measurement, so they are retracted in the doc rather than left
to be discovered later.
libgallium references 97 C++ mangled llvm:: symbols alongside 233 C API ones,
and every one carries an @LLVM_20.1 symbol version tag; libLLVM.so.20.1
exports exactly one version node. So the coupling is exact to major.minor:
"upgrade libLLVM independently" is false — bumping it requires rebuilding
mesa — and "a future consumer can share it" only holds for a consumer on the
same LLVM major. Ubuntu says the same thing in its own way: every other
mesa-libgallium dependency carries a version range, libllvm20 carries none,
because the major is in the package name.
The split is still worth doing, for three narrower reasons that hold:
* a mesa patch release re-fetches 104 MB instead of 241 MB, and LLVM moves
twice a year against mesa's monthly stable patches;
* it is how every distro cuts it, so the version relationship is legible;
* CI cannot upload assets over ~8 MiB to GitCode at all (measured in #371:
15-30 KB/s cross-border, every method times out), so each release already
needs a manual CN-side mirror — and after the split only the 104 MB half
needs it monthly.
What makes the split safe is that a mismatch is a load-time failure, not
silent corruption: symbol versioning is fail-closed. And the exact pin it
requires is the existing idiom, not a new burden — gcc.lua already pins
xim:glibc@2.39.
Also records when NOT to split: if xlings fixes one mesa version and rarely
moves it, all three reasons evaporate and vendoring is the simpler choice.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Throwaway diagnostic. Do NOT merge. Answers: can the GitHub CI actually upload large assets to GitCode, or is it a cross-border network wall?
Background: v0.4.65's mirror job stalled on every asset >8 MiB (killed at 90s), while the identical files uploaded in ~10s from a CN developer machine via the same
gtc. This isolates whether any upload strategy works from an Azure-US runner.The single job (all other workflows deleted on this branch to avoid noise) uploads the real 27 MiB
xlings-0.4.65-linux-aarch64.tar.gzto a throwawayci-upload-proberelease via:gtc-baseline— the exact failing path (Python urllib PUT)curl-default,curl-http1.1— protocol isolationcurl-rate-300k,curl-rate-1m— throttled, to dodge burst-limitingEach reports rc, bytes uploaded before stall, speed, wall time, and download-verify. Cleanup best-effort deletes the probe release.