ci: retry submodule fetch on transient github.com 500s

[Fedr]

Summary

Submodule clones over github.com periodically fail with HTTP 500 in CI. Captured in run 24845654039 on Windows:

error: RPC failed; HTTP 500 curl 22 The requested URL returned error: 500
fatal: expected 'packfile'
fatal: clone of 'https://github.com/AcademySoftwareFoundation/openvdb' into submodule path 'thirdparty/openvdb/v9/openvdb' failed

Six different third-party submodules failed inside ~25 s on that run (openvdb, parallel-hashmap, tinygltf, tinyxml2, zlib-ng, openvdb/v10) — pure github.com flakes, not infra on our side. The hit was on Windows but the same risk exists on every workflow that does git submodule update --init for our third-party tree.

actions/checkout@v6 does have built-in retry logic, but it only retries each submodule once and that wasn't enough to ride out the ~25 s spike.

Change

Wrap the existing selective git submodule update calls in scripts/retry.sh — the 3x/30s retry helper master already ships and that the Rocky vcpkg Dockerfiles already use:

- name: Checkout third-party submodules
  run: |
    # Selective init -- parent Checkout drops submodules:true.
    # https://github.com/actions/checkout/issues/1779
    # Retried via retry.sh: submodule endpoints occasionally 500.
    bash scripts/retry.sh -- git submodule update --init --depth 1 \
      thirdparty/imgui \
      ...
    # mrbind needs deps/cppdecl; recurse only there
    bash scripts/retry.sh -- git -C thirdparty/mrbind submodule update --init --depth 1 deps/cppdecl

Three attempts with a 30 s cooldown — enough to ride out the ~25 s github.com 500 spike observed in the failing run. Only behavioral delta vs master (#5992 for the selective-list pattern itself) is the retry.sh wrapper; the submodule lists, --init --depth 1, and the cppdecl recursion are all unchanged.

Scope

All 8 workflows that do a "Checkout third-party submodules" step:

• build-test-windows.yml (the originally-failing one)
• build-test-macos.yml
• build-test-ubuntu-x64.yml
• build-test-ubuntu-arm64.yml
• build-test-linux-vcpkg.yml
• build-test-emscripten.yml
• pip-build.yml (workflow_dispatch / release — not exercised by PR CI)
• update-docs-manual.yml (workflow_dispatch only — not exercised by PR CI)

Each gets the same two-line edit (one # Retried via retry.sh: ... comment, two bash scripts/retry.sh -- prefixes). Wrapper form is identical across all 8.

Why not Wandalen/wretry.action

An earlier attempt on this PR wrapped the whole actions/checkout step in Wandalen/wretry.action@v3.8.0. It triggered a startup_failure — the workflow parser refused to schedule any job. Root cause appears to be that wretry.action's outer composite-action layer dispatches to an inner _js_action running node20, but actions/checkout@v6 uses node24; the handoff doesn't work and the whole workflow is rejected before any step runs. wretry.action is thinly maintained and has an open issue (#193) with no ETA for a fix, so an in-workflow retry via scripts/retry.sh is the right trade.

Test plan

• Full CI matrix on cbefd973 — run 25015648390 all green:
  • windows 4/4, macos 3/3, ubuntu-x64 3/3, ubuntu-arm64 2/2, linux-vcpkg 4/4, emscripten 3/3 (19/19 build-test legs).
  • First-attempt success on every leg — retry.sh warnings silent (i.e. no submodule needed a retry on this run; the wrapper is a no-op on the happy path).
• Earlier windows-only commit a9cfc67a validated the wrapper in isolation — run 25009155998, 4/4 windows legs green.
• pip-build.yml and update-docs-manual.yml aren't reached by PR CI; their edits are identical two-line copies of the verified pattern.
• If a future CI run hits a github.com 500 during submodule fetch, retries kick in and the job still succeeds.

[oitel]

Keep the old comment.

[Fedr]

Restored — moved the comment back inside the run: block in 80d1f23.

[oitel]

Where did this comment go?

[Fedr]

Good catch — restored in 80d1f23 right above the cppdecl line.