Fix failing windows builds in CI by frostebite · Pull Request #820 · game-ci/unity-builder

frostebite · 2026-03-14T03:59:32Z

Key Note

Observe windows docker builds passing reliably even IN THIS PR

Summary

Add a proactive Docker daemon health check step to the Windows build workflow, before the first build attempt
The windows-2022 runner images sometimes have the Docker service stopped or still starting, causing the first build to fail on Docker operations (see actions/runner-images#13729)
The new step polls the Docker service for up to 60 seconds, actively starting it if stopped, giving clear diagnostic output on each retry

Why keep the existing retry pattern?

The existing retry loop (3 attempts with 120s/240s sleeps) handles multiple transient failure modes beyond Docker -- Unity licensing, network issues, and other flakiness on Windows runners. We keep it as defense-in-depth. This PR only adds a fast, targeted Docker readiness check as a proactive first step so that Docker-specific failures are resolved before the first build attempt rather than burning 6+ minutes of blind sleeping and re-running the full action.

Test plan

Verify the new step runs successfully on windows-2022 runners (Docker service is detected and confirmed ready)
Verify that when Docker is already running, the step exits immediately with "Docker is ready."
Verify the existing retry pattern still triggers correctly for non-Docker failures
Verify that if Docker genuinely cannot start, the step fails with a clear error message after 60 seconds

🤖 Generated with Claude Code

Summary by CodeRabbit

Chores
- Improved Windows build reliability by adding a retrying verification that ensures the Docker daemon is ready before running tests; it will attempt to start the service and fail the job if readiness isn't achieved.
- Reformatted artifact upload naming to a multi-line YAML style while preserving the same computed name.

Add a proactive Docker daemon health check step to the Windows build workflow. The windows-2022 runner images sometimes have the Docker service in a stopped or starting state, causing the first build attempt to fail on Docker operations. The new step polls the Docker service for up to 60 seconds, actively starting it if stopped, before proceeding to the build. This is faster and more diagnostic than relying solely on the existing retry loop (which sleeps 120-240s between full re-runs of the action). The existing retry pattern is kept as defense-in-depth since it also handles non-Docker transient failures (Unity licensing, network, etc). Ref: actions/runner-images#13729 Co-Authored-By: Claude Opus 4.6 <[email protected]>

coderabbitai · 2026-03-14T03:59:50Z

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 9b60084f-68d0-422d-aaf3-92e43de0465a

📥 Commits

Reviewing files that changed from the base of the PR and between 67351b6 and bdac001.

📒 Files selected for processing (1)

.github/workflows/build-tests-windows.yml

📝 Walkthrough

Walkthrough

A new PowerShell step is added to the Windows CI workflow to ensure the Docker daemon is ready: it retries up to 10 times with 6-second waits, starts the Docker service if stopped, verifies responsiveness via docker version, and fails the job if readiness isn't achieved. The artifact upload name field was reformatted to a multi-line YAML string (content unchanged).

Changes

Cohort / File(s)	Summary
Windows Workflow Configuration `.github/workflows/build-tests-windows.yml`	Added "Ensure Docker daemon is ready" PowerShell step with retry/start/verify logic (10 retries, 6s wait). Reformatted artifact upload `name` to a multi-line YAML string while preserving content.

Sequence Diagram(s)

sequenceDiagram
    participant Runner
    participant PowerShellStep as Ensure-Docker-Step
    participant WindowsService as Docker-Service
    participant DockerCLI as docker

    Runner->>PowerShellStep: start step
    PowerShellStep->>WindowsService: query service status (Get-Service)
    alt Service Running
        PowerShellStep->>DockerCLI: run `docker version`
        DockerCLI-->>PowerShellStep: responds
        PowerShellStep-->>Runner: exit success
    else Service Stopped
        PowerShellStep->>WindowsService: Start-Service
        PowerShellStep->>WindowsService: poll status (retry up to 10, wait 6s)
        alt Becomes Ready
            PowerShellStep->>DockerCLI: run `docker version`
            DockerCLI-->>PowerShellStep: responds
            PowerShellStep-->>Runner: exit success
        else Not Ready
            PowerShellStep-->>Runner: fail job
        end
    end

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Suggested reviewers

davidmfinol

Poem

🐰 I nudge the daemon, soft and sly,
Ten little tries beneath the sky,
Six-second naps between each call,
I wake the pond so builds don't stall,
Hops and bytes — workflows all!

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'Fix failing windows builds in CI' clearly relates to the main change—adding a Docker daemon health check to resolve Windows runner build failures.
Description check	✅ Passed	The description includes a comprehensive summary with technical rationale, test plan, and justification for design decisions, covering most required template sections despite minor formatting differences.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch fix/windows-docker-readiness

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

coderabbitai

🧹 Nitpick comments (1)

.github/workflows/build-tests-windows.yml (1)
72-73: Optional: Consider adding a timeout-minutes for this step.

While the script has an internal 60-second timeout, adding an explicit timeout-minutes: 2 to the step would provide an additional safeguard against unexpected hangs (e.g., if Start-Service or Get-Service blocks indefinitely in edge cases).
       - name: Ensure Docker daemon is ready
         shell: powershell
+        timeout-minutes: 2
         run: |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.github/workflows/build-tests-windows.yml around lines 72 - 73, Add an
explicit step-level timeout to the "Ensure Docker daemon is ready" workflow step
by adding a timeout-minutes: 2 property to that step; this augments the script's
internal 60s guard and prevents the PowerShell step (named "Ensure Docker daemon
is ready" which runs shell: powershell and uses Start-Service/Get-Service) from
hanging indefinitely.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In @.github/workflows/build-tests-windows.yml:
- Around line 72-73: Add an explicit step-level timeout to the "Ensure Docker
daemon is ready" workflow step by adding a timeout-minutes: 2 property to that
step; this augments the script's internal 60s guard and prevents the PowerShell
step (named "Ensure Docker daemon is ready" which runs shell: powershell and
uses Start-Service/Get-Service) from hanging indefinitely.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 1add371c-78f0-4794-81e4-0189c08a0ea3

📥 Commits

Reviewing files that changed from the base of the PR and between 9d47543 and 67351b6.

⛔ Files ignored due to path filters (1)

dist/index.js.map is excluded by !**/dist/**, !**/*.map

📒 Files selected for processing (1)

.github/workflows/build-tests-windows.yml

github-actions · 2026-03-14T04:08:58Z

codecov · 2026-03-14T04:24:50Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 31.23%. Comparing base (ce7ce7a) to head (bdac001).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #820   +/-   ##
=======================================
  Coverage   31.23%   31.23%           
=======================================
  Files          84       84           
  Lines        4565     4565           
  Branches     1103     1054   -49     
=======================================
  Hits         1426     1426           
  Misses       3139     3139

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

GabLeRoux

Looks good to me, let's fix merge conflicts. CodeRabbitAI suggested an additional safeguard on the step with a timeout. Might be worth adding, but this will most likely be better with that docker readiness than without it 👍

Note: I did not review dist/index.js.map changes.

Resolve merge conflict in dist/index.js.map by rebuilding dist from merged source. Add timeout-minutes: 2 to the "Ensure Docker daemon is ready" workflow step as a safeguard against indefinite hangs. Co-Authored-By: Claude Opus 4.6 <[email protected]>

Co-Authored-By: Claude Opus 4.6 <[email protected]>

coderabbitai bot reviewed Mar 14, 2026

View reviewed changes

frostebite requested review from GabLeRoux and webbertakken March 25, 2026 12:13

frostebite changed the title ~~ci(windows): add Docker daemon readiness check before build~~ Fix failing windows builds in CI Mar 25, 2026

GabLeRoux approved these changes Mar 25, 2026

View reviewed changes

frostebite and others added 2 commits March 28, 2026 21:00

style: apply Prettier formatting to workflow files

bdac001

Co-Authored-By: Claude Opus 4.6 <[email protected]>

frostebite removed the request for review from webbertakken March 28, 2026 21:03

frostebite merged commit 4a7fc08 into main Mar 28, 2026
62 of 64 checks passed

frostebite deleted the fix/windows-docker-readiness branch March 28, 2026 21:43

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Fix failing windows builds in CI#820

Fix failing windows builds in CI#820
frostebite merged 3 commits intomainfrom
fix/windows-docker-readiness

frostebite commented Mar 14, 2026 •

edited by coderabbitai bot

Loading

Uh oh!

coderabbitai bot commented Mar 14, 2026 •

edited

Loading

Walkthrough

Changes

Sequence Diagram(s)

Estimated code review effort

Suggested reviewers

Poem

Uh oh!

coderabbitai bot left a comment

Uh oh!

github-actions bot commented Mar 14, 2026

Uh oh!

codecov bot commented Mar 14, 2026 •

edited

Loading

Uh oh!

GabLeRoux left a comment •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

frostebite commented Mar 14, 2026 • edited by coderabbitai bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Key Note

Summary

Why keep the existing retry pattern?

Test plan

Summary by CodeRabbit

Uh oh!

coderabbitai bot commented Mar 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Changes

Sequence Diagram(s)

Estimated code review effort

Suggested reviewers

Poem

Uh oh!

coderabbitai bot left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Mar 14, 2026

Uh oh!

codecov bot commented Mar 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

GabLeRoux left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

frostebite commented Mar 14, 2026 •

edited by coderabbitai bot

Loading

coderabbitai bot commented Mar 14, 2026 •

edited

Loading

codecov bot commented Mar 14, 2026 •

edited

Loading

GabLeRoux left a comment •

edited

Loading