FIX: Retry misuka fetches including submodules

[mberz]

To avoid GitHub rate limits and transient submodule failures.

Checkout submodules sequentially
Add sequential retries with increasing delays

[Copilot]

🟢 Approval recommended

The change is small, localized to the Docker build, and the retry/sequential logic aligns with the PR goal; remaining feedback is limited to minor clarity/efficiency nits.

Pull request overview

This PR improves the reliability of building the misuka_method Docker image by making the misuka source checkout more resilient to transient GitHub fetch/submodule failures and rate-limit related flakiness.

Changes:

• Add retry loops (up to 5 attempts) around git fetch and git submodule update, with increasing backoff delays.
• Force submodule updates to run sequentially (--jobs 1) to reduce parallel GitHub requests.

File summaries

File	Description
misuka_method/Dockerfile	Adds sequentialized, retried misuka fetch + submodule update to reduce build flakiness.

Review details

Suppressed comments (1)

misuka_method/Dockerfile:70

• Similarly, on the final submodule update attempt, the code sleeps before exiting. If attempt 5 fails, the build will still wait an extra 50s even though it will exit. Check for the last attempt before sleeping (and adjust the message accordingly).

        git submodule update --init --recursive --depth 1 --jobs 1 && break; \
        echo "submodule update failed (attempt $i/5), retrying in $((i*10))s..." >&2; \
        sleep $((i*10)); \
        [ "$i" = "5" ] && exit 1; \

• Files reviewed: 1/1 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.