Windows Instances Hanging Before Install



I attempted to add Windows instance testing into a repository earlier today and encountered a few issues.

  1. “lts/*” support from NVS. (
  • Not necessarily a Travis issue, but we use “lts/*” with NVM to ensure tests are run on the latest LTS version of Node (its the only version we support for developer machines).
  • Looks like NVS supports a similar feature but it’s version scheme is “lts”.
  • Hardcoding major versions seems to be the path others have had success with.
  1. After specifying “8” as the Node version, Windows instances hang after startup. (
  • This one is quite strange, as it appears the instances are not even attempting to clone the repo.
  • Unable to determine next steps here, but likely will hold off a bit and see if others are having success.

Hope this is useful information! I’m going to experiment a bit more and see if I can resolve the issues.

  • Kris

NVS version strings are different from NVM's

Thanks for the great feedback!

  1. The choice of NVS as the version manager for Node.js was due to initial problems we’ve had with nvm. This may change, or we could work with NVS maintainers to bridge the gaps you mention between NVS and NVM. Stay tuned.
  2. We have seen the hang that you describe. The common factor that leads to this situation is having a secure environment variable, whether it’s in Settings, or in .travis.yml. We have some ideas about the cause, and are investigating.

Again, thank you for testing Windows on Travis CI!


I’m really excited to have Windows support on Travis. Thank you for working in this direction!

We have the same problem #2.

We have only GH_TOKEN in Environment Variables configurations for the repository.


I have a similar issue to the first point - I have my project set to test against node.js 6, 8, and ‘stable’ but nvs doesn’t seem to recognize ‘stable’. I’ll switch it to 10 for now, but ‘stable’ would be a nice feature to get back.

Despite that, it’s awesome to be able to test on windows on travis. That combined with the build stages means I should never ship another release that doesn’t work on windows!


The issue you are experiencing is a bit different, it is due to the GH_TOKEN secure env var and how we filter them from the logs.

For now, we recommend not using Windows with secure env vars while we address this issue.

Thank you for this information!


Adding stable would be great!

One way you could help us is by sending NVS ( a PR which adds this support.

NVS version strings are different from NVM's

NVS maintainer here. NVS does not recognize a version string such as “lts/boron” because that’s not the way NVS version strings are designed to work. In a two-part version string, the part before the slash is supposed to be one of the remotes configured in settings.json. (A remote can name an alternate Node.js download location such as “nightly” or another fork of node such as “chakracore” with builds published in the same format.)

So to add an LTS version of node, the correct command is nvs add node/boron, or just nvs add boron (since node is the default remote).

Note it is explicitly not a goal of NVS to support all of the same command-line syntax as NVM, because the two tools have many different capabilities. But I suppose I could consider recognizing “lts” as a special-case, to ease migration from NVM.

NVS version strings are different from NVM's

Fixed in nvs@1.5.0 .

I decided it will be easier for everyone if nvs can just be smarter and recognize that LTS version syntax, which people coming from nvm are likely to use.


Whoa. Thank YOOOOU!


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



@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