mirror of
https://github.com/QwenLM/qwen-code.git
synced 2026-08-25 16:44:36 +00:00
65c2bb01c0
* fix(ci): narrow serve-ab's self-hosted wipe to the A/B checkout dirs 'Wipe stale workspace before checkout' deleted the whole shared workspace including the root .git, forcing the next job on that runner (e.g. a fetch-depth: 0 review job) to re-download the full ~900 MB of history from github.com. On the ECS pool's slow link that stalls checkouts for 20+ minutes and the fetches drop mid-pack often enough to read as hung runners (2026-08-15: 20 orphaned tmp_pack files, ~6 GB, across 10 runners; one checkout re-downloaded 890 MB in 19m45s). serve-ab only builds inside its own head/ and base/ checkouts and never reads the workspace root, so removing just those two dirs keeps the anti-bleed guarantee without destroying the shared object store. The ci-runner-routing pin now asserts the narrow scope and fails on a whole-workspace wipe regression. * test(ci): derive serve-ab wipe pin from the checkout paths (#9228) Address review suggestions: the wipe targets are now derived from the actions/checkout steps, and the wipe must be exactly one executed (non-comment) rm line covering exactly those paths. Renamed checkout paths, appended whole-workspace wipes, and commented-out or echo'd rms now all fail the suite, while the reverted find-form still does. * test(ci): pin the serve-ab wipe's full executed script and step order (#9228) * fix(ci): match serve-ab's wipe step name and pin to its narrowed scope (#9228) Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * fix(ci): exclude the shared root .git from serve-ab's self-hosted wipe (#9228) Replace the head/base-only rm with the exclusion-based find suggested by the R5-3 review: everything is wiped except the shared root .git, which closes the recurring materializer-coverage class (R4-4/R5-1/R5-2/R5-3) at the layer that owns it — anything landed outside .git is removed by the next run's wipe, no matter how it was materialized. This removes a strict subset of what main's whole-workspace wipe removes, so it cannot regress base behavior, while keeping the .git whose destruction forced ~900 MB re-fetches on the ECS pool's slow link. The pin now also locks the execution chain (shell wrapper, no continue-on-error, no BASH_ENV at step/job/workflow level) per R5-4, and the obsolete clone-coverage scan is deleted. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * fix(ci): keep only a real .git and scrub its exec state in serve-ab wipe (#9228) * fix(ci): follow a symlinked workspace root in the serve-ab wipe (#9228) * fix(ci): defang the worktreeConfig bypass and anchor the serve-ab wipe scrub (#9228) The kept-.git wipe tail had two measured holes: extensions.worktreeConfig activates .git/config.worktree, a second local file that git config --local neither lists nor unsets, so a planted core.hooksPath survived the allowlist sweep; and after the heal unlinks a symlinked workspace root the step's CWD still is the link's target, so the CWD-discovered scrub wrote outside the workspace. Add qwen-triage's hardened defang pair (delete config.worktree, unset the extension) and anchor every git call to $WS/.git. Both findings reproduced locally before the fix; both suites pin the new lines and are mutation-tested. --------- Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> |
||
|---|---|---|
| .. | ||
| actions | ||
| assets | ||
| ISSUE_TEMPLATE | ||
| scripts | ||
| workflows | ||
| actionlint.yaml | ||
| CODEOWNERS | ||
| dependabot.yml | ||
| issue-owners.json | ||
| pull_request_template.md | ||
| release.yml | ||
| spam-blocklist.txt | ||