Windows Instances Hanging Before Install


#1

Hello,

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

  1. “lts/*” support from NVS. (https://travis-ci.org/ampproject/worker-dom/jobs/440339775)
  • 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. (https://travis-ci.org/ampproject/worker-dom/jobs/440369244)
  • 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
#2

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!


#3

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

We have the same problem #2.

https://travis-ci.org/stylelint/stylelint/jobs/440399336

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


#4

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!


#5

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!


#6

Adding stable would be great!

One way you could help us is by sending NVS (https://github.com/jasongin/nvs) a PR which adds this support.


NVS version strings are different from NVM's
#7

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
#8

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.


#9

Whoa. Thank YOOOOU!


#10

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


#11

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


#12

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!


#13

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

Thanks.