Can we drop Node.js: 6.14 from travis JavaScript test matrix?



Recently (over the last month or so) we keep on having OOO failures in many tests using nodejs 6.14, I wonder if there is a way to stop using node 6 to build webpack assets? the 6.14 version is very slow compared to 10 or 8?

perhaps we can offer a docker container that build the assets, and we could use it on our builders (as its not really required to use the OS node versions?)


We do use node 6.14 in forklift’s centos7-devel box. I think we should upgrade the node version in the dev box if we are removing from testing. Which we should probably do anyway, I’ve seen js test result mismatches between jenkins and dev env because of it (afaict its due to node/npm version mismatch between jenkins and dev env).


One of the reasons we’ve kept nodejs 6.Y is due to what EPEL provides and thus the build environment for RPMs provides. Debian is a bit freer in this regard. The worry being if we test with a nodejs not used in these environments we are setting ourselves up to fail further down the line where issues are more costly for developers.


@ehelms I’m fully aware of the motivation, and thats why I suggested an alternative way of building the bundles using docker.

My concern is that I’m not sure how to handle OOO issues on travis, we could in theory run it on circle ci or jenkins, but imho we can just build it using one node version and avoid the extra matrix altogether ?


We are already eating the cost of an npm install on Jenkins, moving to use it instead of Travis wouldn’t lose us much (or maybe gain us time) ?

I get the desire to build the bundles outside of packaging and use them in one place. I think the foremanVendor work will help to lay the ground work for this so we should focus getting that work into the codebase.


while I agree with you, ATM we can’t relay on the node 6 test, it fails in over 50% of the cases, and in this case I’m simply going to ignore it going forward (which from mpov we can just disable it).