Common Windows issues
Cannot access variables from the app
You can’t access the variable directly by using
You can reference the variable in subsequent parts of your workflow by using
However, when using a variable to set another variable in the
vars: section, use the following syntax:
environment: vars: VAR_1: ---\$VAR_2\---
Using Command Prompt
The default shell on the Windows machines is
PowerShell, but you need to run scripts using
Command Prompt app directly and pass your script as an argument:
scripts: - name: Run a command in Command Prompt script: | cmd.exe \c YOUR_COMMAND_HERE
Script with spaces and quotes not behaving as expected
When PowerShell sees a command starting with a string, it just evaluates the string. Typically, this means echoing it to the screen:
PS> "C:\Program Files\Unity Hub\Unity Hub.exe" Hello World
If you want PowerShell to interpret the string as a command name, use the call operator (&):
& 'C:\Program Files\Unity Hub\Unity Hub.exe' ...
If you want to use
PowerShell to run an
.exe file with parameters that contain spaces or quotes, use the
Start-Process -NoNewWindow -FilePath "path-to-your-exe-file" -ArgumentList 'your-arguments-are-here' -Wait
Wrong value in base64 encoded environment variables
Scripts fail when using
base64 encoded variables or use incorrect values.
Encoded variables need to be decoded back into their original form before they can be used. For example, to decode a variable
$VAR1 and save the result as variable
PATH, use the following script:
[Text.Encoding]::UTF8.GetString([Convert]::FromBase64String("$env:VAR1")) | Out-File -FilePath $env:PATH
Cannot access the build machine using SSH or VNC/RDP
Linux and macOS machines can be accessed using SSH or VNC. However, the access does not work when using a Windows build machine.
SSH and VNC access is not available on Windows build machines. You can access them using an RDP client instead.
Learn more: Remote access to the build machine.