Repository navigation
fix(ci): tolerate unwritable docker sandbox lock dir on self-hosted runners (#12006) #12016
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
d423d84
7d676ae
02ae429
f341329
d75b0bb
59f5cc6
407887f
2bbc218
1cf3bc9
e2993f3
ba66904
1effcfb
301c1bb
10540b6
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
) Address review feedback on the lock-dir fallback: - The prune step blanked a job-private resolver result but still logged "skipped because the shared daemon is active", and its resolver-absent inline probe checked only the directory, so a root-owned 0400 lock file failed `exec 9>` with EACCES inside the if-condition (no bash -e abort) and the step exited 0 with that false line as its only output. The step now probes the lock file inline, carries the cause it actually observed (naming the lock dir or file), and announces the unconditional dangling prune separately so "skipped" scopes to the labelled one. Its resolver call blanks GITHUB_STEP_SUMMARY: the step discards a job-private result and opens no lock in it, so the fallback banner would lie there (the leg's calls keep it). - The resolver's fallback warning and summary claimed "docker build/prune coordination is lost" even when only a build-family lock fell back; both now scope the loss to the locks the call actually probed ($*). - Tests: pin the unwritable-dir cause text at both reach points (and fix the comment that claimed it was pinned), add the success-direction witness driving the resolver and the step's shared-dir guard together so a one-token drift between them reddens, and assert the opened-locks == probed-locks invariant as a derived set so a lock added to an exec line without a probe-list entry fails the suite.
- Loading branch information
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -334,18 +334,40 @@ jobs: | |
| # lock lands on the shared dir: taken in a job-private dir it | ||
| # excludes nothing (no other process opens that file), so the | ||
| # prune would race sibling legs' in-flight docker work. | ||
| ci_lock_dir="$(bash .github/scripts/resolve-ci-lock-dir.sh docker-sandbox-daemon.lock)" || { | ||
| # GITHUB_STEP_SUMMARY= blanks the resolver's banner for this one | ||
| # caller: this step discards a job-private result and opens no | ||
| # lock in it, so the banner's "this job locks in <dir>" would lie. | ||
| ci_lock_dir="$(GITHUB_STEP_SUMMARY= bash .github/scripts/resolve-ci-lock-dir.sh docker-sandbox-daemon.lock)" || { | ||
| ci_lock_dir="${HOME}/.cache/qwen-code-ci" | ||
| mkdir -p "${ci_lock_dir}" && [ -w "${ci_lock_dir}" ] || ci_lock_dir='' | ||
| daemon_lock="${ci_lock_dir}/docker-sandbox-daemon.lock" | ||
| if mkdir -p "${ci_lock_dir}" && [ -w "${ci_lock_dir}" ]; then | ||
| # Probe the lock FILE, not only the dir: a root-owned 0400 | ||
| # leftover fails `exec 9>` with EACCES inside the if below, | ||
| # which bash -e does not abort on. | ||
| if [ -e "${daemon_lock}" ] && [ ! -w "${daemon_lock}" ]; then | ||
| skip_reason="${daemon_lock} is not writable by this job" | ||
| ci_lock_dir='' | ||
| fi | ||
| else | ||
| skip_reason="cannot create a writable ${ci_lock_dir}" | ||
|
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Deferred to the follow-up queue. The maintainer confirmed this by mutation (issue comment 5747435862, section 5): deleting 中文说明转入后续跟进队列。维护者已通过变异测试确认(issue 评论 5747435862 第 5 节):删掉 |
||
| ci_lock_dir='' | ||
| fi | ||
| } | ||
| [ "${ci_lock_dir}" = "${HOME}/.cache/qwen-code-ci" ] || ci_lock_dir='' | ||
| if [ -n "${ci_lock_dir}" ] && exec 9>"${ci_lock_dir}/docker-sandbox-daemon.lock" && flock --nonblock 9; then | ||
| if [ -n "${ci_lock_dir}" ] && [ "${ci_lock_dir}" != "${HOME}/.cache/qwen-code-ci" ]; then | ||
| skip_reason="the shared lock dir ${HOME}/.cache/qwen-code-ci is not usable by this job" | ||
| ci_lock_dir='' | ||
| fi | ||
| if [ -z "${ci_lock_dir}" ]; then | ||
| echo "Docker cleanup skipped: ${skip_reason}; clearing ${HOME}/.cache/qwen-code-ci needs a human on this host" | ||
| elif exec 9>"${ci_lock_dir}/docker-sandbox-daemon.lock" && flock --nonblock 9; then | ||
| docker image prune --all --force --filter 'label=org.qwen-code.ci.sandbox=true' --filter 'until=24h' 9>&- || echo "::warning::old CI sandbox image cleanup failed on ${RUNNER_NAME:-this runner}" | ||
| else | ||
| echo "Docker cleanup skipped because the shared daemon is active" | ||
| fi | ||
| # The dangling prune removes only untagged, unreferenced images, | ||
| # so it needs no daemon lock and stays unconditional. | ||
| # so it needs no daemon lock and stays unconditional — announced | ||
| # separately so a "skipped" line above scopes to the labelled one. | ||
| echo "Running the unconditional dangling prune" | ||
| docker image prune --force --filter 'until=24h' 9>&- || echo "::warning::docker image prune failed on ${RUNNER_NAME:-this runner}; dangling images may accumulate" | ||
|
|
||
| e2e-test-macos: | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Deferred to the follow-up queue, per the maintainer's end-to-end verification (issue comment 5747435862): the finding is confirmed real — on a poisoned host this step discards the resolver's job-private result yet still publishes its
::warning::, so the annotation names a lock dir this step never opened — and the maintainer explicitly asked for it to be filed (with R9-4) as a diagnostics follow-up rather than block this PR. Recorded in the deferred-findings queue so it survives the merge; leaving this thread open.中文说明
按维护者的端到端验证结论(issue 评论 5747435862)转入后续跟进队列:该发现已被确认属实——在中毒主机上,本步骤丢弃了 resolver 的作业私有结果,却仍发布其
::warning::,导致注解指向一个本步骤从未打开过的锁目录——维护者明确要求将它(连同 R9-4)作为诊断信息后续项建档,而不是阻塞本 PR。已记录进 deferred-findings 队列,合并后仍会保留;本线程保持未解决状态。