I needed an explicit cleanup before starting my tests to have then working again. Is that normal?

Languages Node.js
1

Hi,

I have a node-based application in github (https://github.com/telefonicaid/iotagent-ul) connected to travis, so tests are run in each pull request. My application depends on a library (named “iotagent-node-lib” and included as dependency in the packages.json file of my application). Recently iotagent-node-lib changed and since that moment, my application tests started to fail in travis although in my own Linux system the tests keep working…

Just to try, I decided to include a cleanup step in the install stage of my .travis.ymll file (“npm run clean” wich translate to a rm on the packages-lock.json file and node_modules/ directory). And it worked!

It can be seen in this PR: https://github.com/telefonicaid/iotagent-ul/pull/388. In the first commit, before adding “npm run clean” it failed. In the second commit, which just adds “npm run clean” to .travis.yml, it passed.

I’m a bit surprised (I did the modification to .travis.yml in a desperate attemp to solve the problem :). I guess that packages-lock.json or node_modules were there using the old version of iotagent-node-lib and that made the tests to fail. The cleanup forces to reinstall again and it gets solved. However, I though that each time travis runs the test, the enviornment is cleaned so the environment starts “from the scratch”. Why the explicit cleanup is needed in that case? Maybe I’m wrong in my original guessing?

Any feedback or clarification on this is welcome :slight_smile: Thanks!

Best regards,

Fermín

2

node_modules is in your build cache.

So your build logic needs to account for the case where it already contains something.

My guess is that your package metadata doesn’t properly specify required versions for some of dependencies (possibly transitive ones) thus npm install doesn’t properly update them if there’s already an older version in node_modules.

It’s also possible that iotagent-node-lib's metadata does that rather than yours – and as such, this is a problem with that library (but this still could be worked around by requiring a newer version of a dependency yourself). Very possible since you’re installing a branch head of that library rather than a release.

1 Like
3

Thanks for your feedback! All makes sense after reading your comment :slight_smile:

Although I can solve the case with “npm run clean”, I wonder if it would be possible (by configuration in .travis.yml) to avoid node_modules to be included in the build cache. What do you think?

4

Disabling the cache is possible but will add to your build times – and most importantly, if the metadata isn’t right, your users will eventually see the same breakage that you did.

1 Like