Windows Instances Hanging Before Install

Thank you @jasongin. That’s a welcome change, and much appreciated.

@jasongin Wow, thank you so much for adding this!

Is there an update here?

Our project would be happy even if the env variable was discarded for the moment. Ours are defined in Settings, but there’s a workaround available by moving them to the yaml, we’d be game. Thanks!

Hi, there. We will provide some additional details tomorrow.

For the time being, you might consider disabling the filter that is standing in the way. Do keep in mind that doing so may lead to accidental revelation of secrets. To disable the filter, add this to the top level of your configuration:

filter_secrets: false


1 Like

@BanzaiMan - What does the filter_secrets: false flag do? Is it documented anywhere? I can’t find it on

I try to install nvm in windows using choco install nvm.
I also add in env variables the NVM_HOME and NVM_SYMLINK as they appear not to be there.

After I am setting them they are still empty and nvm -v or npm -v return command not found.
This configurations works fine for macos and linux.

Do you have any idea ?


  • if [[ “$TRAVIS_OS_NAME” == “linux” ]]; then nvm install $NODE_VERSION; fi

  • if [[ “$TRAVIS_OS_NAME” == “osx” ]]; then nvm install $NODE_VERSION; fi

  • if [[ “$TRAVIS_OS_NAME” == “windows” ]]; then choco install nvm; echo $NVM_HOME; export NVM_HOME=C:\ProgramData\nvm; export NVM_SYMLINK=C:\ProgramData\nodejs; echo $NVM_HOME; RefreshEnv.cmd; echo $NVM_HOME; fi # choco install nodejs.install;

  • npm -v

  • ./ci/

@JamesMessinger The feature that this flag controls is explained here.

To prevent leaks made by these components, we automatically filter secure environment variables and tokens that are longer than three characters at runtime, effectively removing them from the build log, displaying the string [secure] instead.

Adding filter_secrets: false will disable the filtering described above.

@gsfakianakis Could your provide us with a link to a build that’s showing the behavior you describe?

Actually I fixed that. Another problem I have is that tests pass when merging from the working branch to development branch, but when I want to merge the development branch to master the windows test is hanging on worker information (i.e. nothing is running).

Travis Test branch to development is here:

Development to master is here:

Hello! Is there any workaround for running the build with secrets env, if not is there any eta for this to be fixed?
As you can see my build get stuck and fails right the command nvs use :sob: without even start the proper build process.

here is the build:

Hi @dominic can you or someone advise a solution for the above issue please, i’m not sure how to go further and i’d love to provide windows support to the app

1 Like

@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.

1 Like

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 token.

1 Like

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.

1 Like

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: ??

When it try to install nvs will pick a wrong version

$ nvs add 11
Downloading bootstrap node from

Last succesful build I had on January 18th: (still different version but build worked well)

$ nvs add 11
Downloading bootstrap node from

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.