fix(ci): bound docs-sync publish repo git clone#109173
Merged
Patrick-Erichsen merged 1 commit intoJul 18, 2026
Merged
Conversation
## Summary - Problem: The `git clone` of `openclaw/docs.git` in `docs-sync-publish.yml` had no timeout bound, risking indefinite CI hangs on network stalls. Same pattern already fixed for Mantis Crabbox workflows in openclaw#108940. - Solution: Add `timeout --signal=TERM --kill-after=10s 120s` before the `git clone` command. - What changed: Wrapped the `git clone` command with timeout, matching the bounded pattern from openclaw#108940. - What did NOT change: All retry logic, publish sync steps, and non-network operations remain unchanged. ## Real behavior proof - **Behavior addressed:** CI docs-sync-publish workflow could hang indefinitely during git clone of external docs repo. - **Real environment tested:** Pattern analysis and cross-reference with already-merged Crabbox fix (openclaw#108940 / 16c2bbb). - **Exact change:** `if timeout --signal=TERM --kill-after=10s 120s git clone \` replaces `if git clone \`. - **Evidence after fix:** Same `timeout --signal=TERM --kill-after=10s 120s` wrapper applied to Crabbox source retrieval. - **What was not tested:** Live CI run. ## Root Cause - The git clone was added before the timeout-bounding pattern was standardized across CI workflows. Missing automated check for unbounded external git operations.
clawsweeper
Bot
added
rating: 🦪 silver shellfish
Contributor
|
Codex review: needs maintainer review before merge. Reviewed July 17, 2026, 5:25 AM ET / 09:25 UTC. Summary PR surface: Config 0. Total 0 across 1 file. Reproducibility: yes. at source level: the original clone has no operation-level deadline, and the contributor's controlled stalled-transport run demonstrates that the patched production command terminates predictably. A naturally occurring GitHub transport stall was not reproduced. Review metrics: 1 noteworthy metric.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Land the bounded clone with its focused acceptance coverage, retaining the five retries and monitoring whether the 120-second per-attempt threshold proves appropriate for the publish repository. Do we have a high-confidence way to reproduce the issue? Yes at source level: the original clone has no operation-level deadline, and the contributor's controlled stalled-transport run demonstrates that the patched production command terminates predictably. A naturally occurring GitHub transport stall was not reproduced. Is this the best way to solve the issue? Yes. Reusing the repository's recently merged bounded-process pattern is narrower and more maintainable than introducing a separate wrapper or new workflow configuration surface. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against d023e8b412c1. Label changesLabel justifications:
Evidence reviewedPR surface: Config 0. Total 0 across 1 file. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
Review history (4 earlier review cycles)
|
clawsweeper
Bot
added
merge-risk: 🚨 automation
github-actions Bot
pushed a commit
to Desicool/openclaw
that referenced
this pull request
Jul 18, 2026
## Summary - Problem: The `git clone` of `openclaw/docs.git` in `docs-sync-publish.yml` had no timeout bound, risking indefinite CI hangs on network stalls. Same pattern already fixed for Mantis Crabbox workflows in openclaw#108940. - Solution: Add `timeout --signal=TERM --kill-after=10s 120s` before the `git clone` command. - What changed: Wrapped the `git clone` command with timeout, matching the bounded pattern from openclaw#108940. - What did NOT change: All retry logic, publish sync steps, and non-network operations remain unchanged. ## Real behavior proof - **Behavior addressed:** CI docs-sync-publish workflow could hang indefinitely during git clone of external docs repo. - **Real environment tested:** Pattern analysis and cross-reference with already-merged Crabbox fix (openclaw#108940 / 05fa39e). - **Exact change:** `if timeout --signal=TERM --kill-after=10s 120s git clone \` replaces `if git clone \`. - **Evidence after fix:** Same `timeout --signal=TERM --kill-after=10s 120s` wrapper applied to Crabbox source retrieval. - **What was not tested:** Live CI run. ## Root Cause - The git clone was added before the timeout-bounding pattern was standardized across CI workflows. Missing automated check for unbounded external git operations.
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
2 participants
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.
What Problem This Solves
Fixes an issue where the
docs-sync-publishworkflow could remain stuck in thegit clonestep until the job timeout when the Git transport toopenclaw/docs.gitstalls. This blocks the entire documentation publish pipeline and wastes runner time.Why This Change Was Made
The
git clonecommand now runs through the repository's bounded process pattern: a 120-second deadline, followed by a 10-second termination grace period. This matches the pattern already applied to Mantis Crabbox workflows in #108940 (commit 16c2bbb). Ref selection, shallow checkout, build, warmup, and sync behavior are unchanged.User Impact
Maintainers get a prompt, actionable checkout failure instead of losing a docs-publish runner for the full job timeout before the sync begins.
Evidence
Regression:
node scripts/run-vitest.mjs test/scripts/package-acceptance-workflow.test.ts --run --testNamePattern="bounds docs-sync publish repo git clone"??1 passed.Controlled runtime proof extracted the production workflow step, scaled the production deadline to one second, and injected a Git transport that stalls until
TERM. The step returned 124 in about 1.03 seconds, the Git fixture observedTERM, and did not reach the five-second outer watchdog. The identical pattern was proven for all five Mantis Crabbox workflows in fix(mantis): stop Crabbox setup hanging on stalled checkout #108940.pnpm exec oxfmt --checkpassed for the changed file;git diff --checkpassed.The complete test suite was also attempted: 72 tests passed, while unrelated environment-dependent cases failed because the isolated host lacked GitHub CLI authentication/clean login-shell state. The affected focused regression is green.