mirror of
https://github.com/QwenLM/qwen-code.git
synced 2026-09-11 19:46:21 +00:00
4167db8797
* fix(ci): give the ECS runner resolve wait a 60-minute budget
The npm-published dispatch raced the registry again for v0.23.0: the
package took ~40 minutes to become resolvable (published 11:03Z,
visible ~11:43Z), but the resolve wait gave up at 25 minutes
(RESOLVE_TIMEOUT_SECONDS=1500) and run 33747588713 failed with the
version still in flight, leaving every pool on the previous version.
Raise the wait to 3600s and the job timeout to 70 minutes to match;
v0.22.3's 16-minute gap was the optimistic data point the old budget
was sized on.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
* fix(ci): size the resolve wait on the measured 55-minute propagation
Measured end to end for v0.23.0: npm accepted the upload at 10:58:30Z
and the registry served the version at 11:53:52Z — 55m22s for the
~100 MB main package, longer than the 60-minute budget the previous
commit carried. Raise the wait to 90 minutes (the anomaly threshold)
and the job timeout to 100 minutes; the 30s poll keeps fast publishes
resolving immediately.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
* ci: print install-prefix diagnostics when the version check fails
hk-4 and hk-5 installed 0.23.0 successfully ("changed 16 packages")
but `qwen --version` still reports 0.22.3 from /usr/local/bin/qwen,
which suggests the sudo npm install lands in a different prefix than
the one the pool resolves. Print the binary's readlink, the candidate
paths, sudo npm's global prefix, and the installed package.json before
failing so the next run identifies the stale copy instead of guessing.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
* fix(ci): pin the fleet install to the /usr/local prefix
Diagnostics on hk-4/hk-5 showed root's npm global prefix there is
/usr/local/lib/nodejs/node-v22.23.2-linux-x64, so `sudo npm install -g`
updated that tree while the pools kept resolving the stale
/usr/local/bin/qwen -> /usr/local/lib/node_modules copy (still 0.22.3).
Install with --prefix /usr/local so every pool updates the copy the
runner service resolves.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
* fix(ci): fall back to a non-sudo install where passwordless sudo is missing
The hk-1/hk-2 pool machines reject sudo with "a password is required"
for the runner user, so the install failed after 3 attempts on two
consecutive runs. Probe passwordless sudo once (sudo -n true) and, when
absent, install as the runner user itself, which succeeds when that
user owns the /usr/local prefix.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
* test(ci): follow the fleet install step's array form
The install command moved to an INSTALL array so the sudo-less fallback
can reuse it, which broke the workflow contract test's literal match.
Assert the new shape instead.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Patrol-Run: qwen-pr-conflict/jmtlp4re4g6
* fix(ci): keep the fleet verify diagnostics usable without sudo
An interactive `sudo` on the no-passwordless-sudo pools — the pools the
install fallback serves — blocks on a password prompt until the job
timeout kills the step, so the Verify diagnostics never print there.
Run every probe as the runner user or with `sudo -n`, and pin the shape
in the workflow's guard suite.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Patrol-Run: qwen-pr-closeout/jmtlz4ubdgq
* fix(ci): capture the fleet qwen version tolerantly in verify
Under `set -euo pipefail` a `--version` that exits non-zero aborts the
Verify step at the bare assignment, before the mismatch diagnostics this
diff exists for can print — the exact failure class of a crashed install.
Capture tolerantly so the step still fails at the version test, now with
diagnostics, and pin the shape with a replay of the Verify step body.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Patrol-Run: qwen-pr-closeout/jmtlz4ubdgq
* test(ci): pin the fleet resolve budget against the job timeout
The replay harness injects its own budget values, so nothing guarded the
shipped ones: a bad merge resolution lowering the job timeout below the
wait would let GitHub kill the poll mid-propagation and silently restore
the v0.23.0 failure. Assert both constants and their invariant.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Patrol-Run: qwen-pr-closeout/jmtlz4ubdgq
* fix(ci): capture the fleet qwen version from stdout only
The tolerant version capture merged stderr into the string the step
strict-matches: one stderr line during `--version` (a Node runtime
warning, a future startup notice) would fail a healthy install on every
pool, print mismatch diagnostics claiming a stale fleet, and file a
stale-fleet issue against a correctly updated fleet. The `|| actual=`
arm already covers the failing path, where the merged stderr bought
nothing. Move the pin to the stdout-only shape and replay a
stderr-noisy success.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Patrol-Run: qwen-pr-closeout/jmtme4yqxhl
* test(ci): assert the sudo probe class instead of today's verbs
The guard enumerated the three sudo verbs the Verify step happens to
use, so a bare `sudo` with any other verb passed it and could block on
an interactive password prompt until the job timeout — on exactly the
no-passwordless-sudo pools the diagnostics exist for. Assert the class
the test's own comment documents, every sudo probe must be
non-interactive, on the non-comment lines; the probe comment mentions
`sudo` in prose, so it stays out of the check.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Patrol-Run: qwen-pr-closeout/jmtme4yqxhl
* fix(ci): pick the ECS install mode by running it, not by probing sudo
The `Update qwen` step gated its install mode on a `sudo -n true` probe.
hk-1/hk-2 carry command-specific sudoers: they reject that generic probe
and allow the real npm install, so the probe selected the runner-user
mode on exactly the machines that could have installed as root. That
mode then hit EACCES against the root-owned package dir on all three
attempts, and those two pools could never update: every `npm-published`
dispatch would lose the hk-1/hk-2 legs and leave them on the old CLI
until someone intervened.
No probe can be more representative than the command it stands in for,
so run the sudo mode first and fall back to the runner-user mode only
when sudo actually rejects it. That is the shape the pre-change workflow
already ran green on all five pools, and the fallback still serves pools
with no passwordless sudo at all. Every sudo in the step is now `-n`,
the trash cleanup included, so a pool without sudo fails fast into the
next mode instead of blocking on a password prompt until
`timeout-minutes: 10` kills the step.
Also replay the `Update qwen` step body against stubbed sudo/npm/sleep
modelling all three sudoers classes and both prefix owners, asserting
the effective user npm ran as rather than only the exit code: a
fallback that succeeds after a wasted runner-user EACCES attempt is the
regression this fixes. Reverting the workflow change reds five tests.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Patrol-Run: qwen-pr-closeout/jmto4amd1ku
* fix(ci): try the sudoers-named argv as its own install mode
hk-1/hk-2 authorize one exact command line and it carries no --prefix,
so the pinned sudo argv is rejected there ("sudo: a password is
required"; run 33754421601 has hk-1/hk-2 red while hk-3/4/5 are green)
and the step fell through to the runner user, which EACCESes on the
root-owned package dir on all three attempts. Dropping the pin instead
would regress hk-4/hk-5, whose root prefix is a custom Node directory
(run 33754034666 is the mirror image: hk-1/hk-2 green, hk-4/hk-5 red).
No single argv serves both, so add the authorized shape as an ordered
second sudo mode -- after the pinned one, before the runner-user
fallback.
Also narrow the replay's command-specific sudoers stub from a substring
match on " npm install -g " to the two argv the real spec names, so the
suite can see this class. Measured: with the narrowed stub, deleting the
new mode or re-adding --prefix to it reds "installs as root on a pool
whose sudoers allows only the npm install" (2 failed | 32 passed both
ways); at this head it is 34 passed (34).
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Patrol-Run: qwen-pr-closeout/jmtof0f82lb
* ci: record the ECS updater workflow's real size
check-workflow-size.sh red-walled the lint lane on this PR: the file
grew to 12618 bytes, 5431 over its recorded 7187 and past the 4096
allowance. The growth is real rather than prose that belongs in a
sibling .md -- it is the inline rationale for the three install modes
(pinned sudo for hk-3/4/5, the sudoers-named argv for hk-1/hk-2, runner
user where no passwordless sudo exists) with the two run IDs that
distinguish them, plus the measured v0.23.0 registry-propagation gap
behind RESOLVE_TIMEOUT_SECONDS 5400. Each comment sits next to the
shell it explains, so moving them out would separate the evidence from
the code it justifies.
Verified locally: check-workflow-size.sh exits 0 with
WORKFLOW_SIZE_BASE_SHA set to this PR's base, and the vitest mirror
scripts/tests/workflow-size.test.js passes 202/202.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Patrol-Run: qwen-pr-conflict/jmtooas8sln
* fix(ci): retry a failed npm install in the same mode, not the next one
The three install modes advanced on any non-zero exit, so they could not tell
"sudoers refused this argv" from "npm ran and failed". A transient npm failure
of the pinned mode therefore fell through to the unpinned spec arm, which
hk-4/hk-5's generic sudoers also allows: a retryable npm blip became a root
install into the custom Node prefix the pool never resolves.
Only a sudo refusal advances the chain now. npm prefixes every diagnostic it
prints (`npm error`, `npm warn`, `npm notice`) and sudo prints nothing on npm's
behalf, so the arm's own captured output says whether npm ran at all — no probe
(this step selects no mode by probe, and a `sudo -n -l` gate would depend on
sudo's wording) and no enumeration of refusal messages. An npm failure goes
back to the 3-attempt retry loop in the mode that can install on that pool.
Covered by two new replays in the collocated suite: a transient npm failure of
the pinned mode retries the pinned argv and never reaches the unpinned root
arm, and a sudoers refusal of the pinned mode still advances to the spec
hk-1/hk-2 name and retries that one instead of dropping to the runner user.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Patrol-Run: qwen-pr-closeout/jmtp6vibomd
* fix(ci): advance the install mode only on an identified sudo refusal
The mode chain classified a sudo refusal by the *absence* of `npm `-prefixed
output, so any npm death that prints nothing of its own read as a refusal and
escalated to the unpinned `named-spec` arm. On an hk-4/hk-5 member generic
sudoers allows that argv, so an OOM-killer SIGKILL — or V8's `FATAL ERROR:
Reached heap limit` while unpacking the tarball — installed as root into
/usr/local/lib/nodejs/node-v22.23.2-linux-x64, the prefix the pool never
resolves, and the step exited 0. Three harms survived the `Residual:` comment
that argued only the signal-kill half: the exit 0 is a false certification,
the retry this loop exists to give is spent instead of used, and the stray
root-owned tree sits outside the PKG_DIR cleanup glob.
Invert the polarity so only a refusal the arm can positively identify
advances, and every unrecognised failure retries its own mode and fails
loudly. `^sudo:` is sudo's program-name prefix rather than a wording
enumeration, so the message after it may vary or be localised; the refusal
this fleet really produces is `sudo: a password is required` (run 33754421601,
hk-1 and hk-2 on all three attempts), and both `command-specific` replays
still pass unchanged. Narrowed the `Residual:` comment to what is actually
left: a refusal that is not `sudo:`-prefixed, i.e. sudo absent rather than
unauthorized, which retries and reds the leg instead of reaching the
runner-user mode — and cannot install into the wrong prefix.
The replay suite could not discriminate the two polarities before this: the
npm stub only ever failed by printing `npm error code ENOTEMPTY`, which is the
prefix the old discriminator looked for. Added `npmFailureStyle` as an axis
separate from `npmFailures` — whose premise is that npm speaks for itself —
and a `signal` style that dies without announcing itself, plus a replay
asserting status 1, modes ['root','root','root'], every call pinned to
`--prefix /usr/local`, and the retry warning on stdout. Measured against the
shipped polarity that test reports nine invocations walking all three modes
(pinned, unpinned-root, runner) across three attempts; with the inversion,
three, all pinned.
Also recorded the workflow's new true size in .size-baseline
(12618 -> 16553). The prose above puts the file 3935 bytes past the number the
branch recorded, which is 96% of the 4096-byte allowance the ratchet tolerates
and was the widest gap of any workflow in the repo — exactly the invisible
drift that file exists to turn into one reviewed line.
node --test .github/scripts/update-ecs-runner-qwen-workflow.test.mjs:
37 pass, 0 fail (35 pass / 2 fail with the polarity reverted).
check-workflow-size.sh green; eslint clean on the test file.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Patrol-Run: qwen-pr-closeout/jmtpq5ybkn4
* fix(ci): require a sudo refusal to be the arm's whole story before advancing
`^sudo:` is sudo's program-name prefix, not a refusal marker: sudo prints
non-fatal diagnostics under that prefix while still running the command. So
a transient npm failure of the pinned arm that co-occurs with one --
`unable to resolve host <host>`, routine when the machine's own hostname is
missing from /etc/hosts and observed on a live hk pool member this round, or
a setrlimit notice, or a PAM / audit-log open failure -- was classified as a
refusal: arm_ran_npm=0, the `for mode` loop did not break, and mode 2 ran the
unpinned `named-spec` argv that hk-4/hk-5's generic sudoers also allows. Root
installed into /usr/local/lib/nodejs/node-v22.23.2-linux-x64, that arm
returned 0, and `esac && exit 0` certified the update without ever printing
`:⚠️:npm install attempt 1 failed; retrying` -- the retry written for
the ENOTEMPTY rename race spent instead of used, a root-owned tree left where
the ${PKG_DIR} cleanup glob never reaches it, Verify reds the leg, and
report_failure files a stale-fleet issue blaming the fleet rather than this
step escalating to the wrong argv. Because the warning is a persistent host
condition, every later transient npm failure on that pool escalated the same
way, and the class has no last corner that rewording would close.
Advance only when the refusal is the arm's whole story: a `^sudo:` line,
nothing else on stderr, and nothing on stdout. The conjunction only ever
blocks advancement, so the property the polarity was written for survives --
an OOM-killed or signalled npm leaves no `^sudo:` line at all and still
retries its own mode. The measured residual is narrower than the hole this
closes and is now stated as such above the guard: a warning plus a death
quiet enough to leave BOTH captures holding nothing but `^sudo:` lines would
still advance. A signalled npm does not reach that corner, because
install_qwen is a shell function and bash's own `Killed` diagnostic supplies
the non-`^sudo:` line.
Tests: a `sudoWarning` axis on the replay harness's sudo stub, emitted during
startup before the policy check the way real sudo emits it, so an authorized
arm and a refused one both carry it. `does not read a non-fatal sudo warning
as a refusal to advance` pins the fix (generic sudoers + one transient npm
failure + the warning retries the pinned mode and prints the retry
annotation); `still advances past a refusal on a pool whose sudo also warns`
pins the negative half so the tightening cannot strand hk-1/hk-2 on a mode
they cannot run. Both conjuncts are pinned as strings too, because the replay
arm is skipped on the Windows lane.
Suite: 37 -> 39 pass under `node --test --test-concurrency=1
.github/scripts/update-ecs-runner-qwen-workflow.test.mjs`. Reverting the
one-line guard reds the new case and the string pins (37 pass / 2 fail), so
neither is a tautology. The workflow grows 16553 -> 17647 bytes, inside the
4096-byte ratchet allowance, so .size-baseline is unchanged and
check-workflow-size.sh passes.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Patrol-Run: qwen-pr-closeout/jmtq7b8jgnr
* fix(ci): keep ECS resolver timeout change focused
---------
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Co-authored-by: Shaojin Wen <shaojin.wensj@alibaba-inc.com>
|
||
|---|---|---|
| .. | ||
| actions | ||
| assets | ||
| ISSUE_TEMPLATE | ||
| scripts | ||
| workflows | ||
| actionlint.yaml | ||
| CODEOWNERS | ||
| dependabot.yml | ||
| issue-owners.json | ||
| pull_request_template.md | ||
| release.yml | ||
| spam-blocklist.txt | ||