@BanzaiMan Is there a tracking topic or issue related to your previous comment: Windows Instances Hanging Before Install ?
This is also affecting many of our Windows’ auto-deployment builds. We have some access tokens that are required for deployments, and the Windows builds are failing whenever we add secrets to the builds.
Can confirm my builds fail as well when adding secret environment variables. It’s not an option for me to remove these as my secrets are needed to deploy out to npm and github.
I’m also curious about this, since all jobs fail on Windows when the build contains an encrypted setting with https://codecov.io token.
Any encrypted settings for the project in the Travis CI UI or env: global: - secure: cause Windows jobs to hang. For example, this job got in about 19 lines and then on the first command in before_install it just hangs. No error message, nothing. When I removed the env: global: - secure: and project Environment Variables, it would proceed.
Looks like the same issue as Choco install hangs forever.
It has been suggested in that thread that adding filter_secrets: false can fix the issue. However, doing that seems quite dangerous when bad actors only need to submit a PR containing an env call to see all your secrets.
This issue is probably related to differences in Bash (4.3.48(1)) vs. Windows Bash (4.4.19(2)-release) and the secrets filtering not being compatible with Windows. Maybe somewhere in here: https://github.com/travis-ci/travis-build/tree/master/public/filter ??
When it try to install nvs will pick a wrong version
https://travis-ci.org/Paxa/postbird/jobs/485958838
$ nvs add 11
Downloading bootstrap node from https://nodejs.org/dist/v10.12.0/node-v10.12.0-win-x64.7z
Last succesful build I had on January 18th: (still different version but build worked well)
$ nvs add 11
Downloading bootstrap node from https://nodejs.org/dist/v10.12.0/node-v10.12.0-win-x64.7z
I don’t think so. That’s nvs bootstrapping to install Node.js 11. Your build hangs for the same reason as the others have seen.
right, sorry. I removed global -> secure and it works now
filter_secrets: false can be used on a per-job basis. I personally use it do disable filtering of secrets for Windows hosts and then unset the specified environment variable first thing in before_install:. When the secret is set, it’s still filtered and secrets are always removed for pull requests. Of course this won’t allow you to use the secret in Windows builds, but for my scenario that was good enough (running Coverity Scan on Linux).
Hope this helps other people.