Unity Cloud Build


Windows Builder Public Rollout

As part of our efforts to improve the performance of Cloud Build, we’re beginning the process of shifting our Windows and Android builders to native Windows VMs. This will enable Windows IL2CPP and lower queue times for your builds. Given the scalability of this infrastructure, we anticipate faster build times as well in the near future.

Windows Builder Transition Common Issues

As we transition to our new Windows build machine infrastructure, you may experience some new issues with your builds. Though we are taking action to prevent and fix as many of these issues as possible, there are some things that we cannot fix directly.

This goal of this section is to provide some solutions to known problems that can occur as a result of these new infrastructure changes. We will continue to update this section as we discover new common issues.

FMOD Errors

This issue should be fixed as of September 8th, 2021. If you are still experiencing it, please contact Cloud Build support.

[Unity] FMOD failed to get number of drivers ... : "Error initializing output device. " (60)

Errors involving FMOD like this one are generally not fatal. If your build is failing, we recommend combing through the logs to find the “real” exception causing the failure. With that being said, we are aware of this FMOD issue and are working on a solution.

Some users that are using symlinks or git submodules have reported running into namespace issues. This problem seems to occur for nested libraries either through symlinks or git submodules. Our Windows machines are running in a Cygwin environment and as of now may not be able to properly handle these cases resulting in a message similar to the following:

[Unity] The type or namespace name 'LitJson' could not be found (are you missing a using directive or an assembly reference?)

It is suggested to avoid using symlinks in Unity projects and replacing them with the source directory itself wherever possible. For now, users that are dependent on using symlinks should continue to opt-out of the new windows builder infrastructure. With that being said, our team will be working on investigating a solution to this issue.

Collab and Windows Builders

We are currently experiencing issues running projects hosted in Collab on the new Windows infrastructure. As such, all Collab projects will continue to be run on the old MacOS infrastructure until further notice.

“d3d11 Swap Chain” Error

This issue should be fixed as of September 8th, 2021. Builds may still log this error, but it should not be the cause of failures in most situations. If you believe that this error is causing your builds to fail, please contact Cloud Build support.

There is a known error that seemingly happens under certain circumstances when a plugin tries to open an Editor window. We are in the process of diagnosing and fixing this issue. The logs you can expect to see from this error are as follows:

[Unity] d3d11: swap chain: w=32 h=32 fmt=29
[Unity] d3d11: failed to create swap chain [0x887a0022]
[Unity] <RI> Initializing input.

New Allowed IPs

If using private version control or package servers and are seeing “access denied” or similar errors, you may need to update their security settings to allow access to the IPs used by the new Windows builders. In order to get access to the list of IPs, please contact our support team.

Platform-Specific Custom Scripts

For more information regarding platform-specific custom scripts please see this page.

Windows Max Path Length Issues

Some users are experiencing issues with files exceeding the Windows maximum allowed path length (260 characters). We have taken steps to mitigate most of these errors in the editor, but certain packages can still trigger the issue. Most notably, the Addressables package seems to struggle with this.

We are looking into longer term fixes, but one known technique to mitigate these errors is to shorten the name of your build targets. This way, any paths created with the name of the target will also be reduced in length.

“OVRADBTool * daemon not running; starting now at tcp:5037” error

Some users are experiencing issues when building for Oculus particularly when the the “Strict Mode” option is enabled in the build target advanced settings. The message is as follows:

ERROR: OVRADBTool * daemon not running; starting now at tcp:5037

This happens because the Oculus plugin is running “adb devices” in build time and the daemon isn’t started. When “Strict Mode” is enabled, the Unity Editor considers this a fatal issue. This issue doesn’t happen in macOS builders because the plugin is looking for a file called “adb.exe” and in macOS the file name is just “adb”. As the file isn’t found, the plugin doesn’t proceed and don’t try to run “adb devices”.

In order to fix this, we recommend starting “adb” in a pre-build script in the Windows builders. Find below a sample script:

unameOut="$(uname -s)"
if [[ "$unameOut" == "CYGWIN"* ]]; then
    $ANDROID_HOME/platform-tools/adb.exe start-server