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.
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.
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 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!
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.
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.
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:
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.
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).
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 without even start the proper build process.
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
without even start the proper build process.