Garren, the log shows npm ERR! node v4.2.6 npm ERR! npm v2.14.12
So yeah, npm 3 and node 6 would be preferable :) Joan, let me know if you need help with any of this. Best Jan -- > On 21 Mar 2017, at 13:06, Garren Smith <[email protected]> wrote: > > Hi Joan, > > What version of node and npm is on the build server? I did some googling > around and the best I can find around that npm issue is that it might be an > older npm or there is some connection issues with npm. > We use node 6 with Travis and haven't seen this issue. Is it possible to > cache npm installs locally, that will speed up your build time and possibly > fix this issue. > > Cheers > Garren > > On Mon, Mar 20, 2017 at 7:50 AM, Joan Touzet <[email protected]> wrote: > >> Hello, >> >> I've been getting our CI workflows cleaned up a bit, including >> re-enabling our OS matrix builds on Apache's Jenkins. Today, I finally >> got my first all-green build on Jenkins and Travis at the same time. It >> was a LOT harder than it should have been. >> >> Why? Because our test suite (and build process) inconsistently fails. >> I need your help to stabilize the build so we can rely on CI again. >> I also need your help because I can't do all the work myself. >> >> We have 1 build failure and 5 test failures that I'm aware of. >> >> >> Currently there is one strict build failure, in fauxton. I believe this >> is a transient failure of trying to pull down an npm package: >> >> -------------------------- >> [email protected] node_modules/grunt-couchapp >> ├── [email protected] ([email protected], [email protected], [email protected]) >> ├── [email protected] ([email protected], [email protected], [email protected]) >> └── [email protected] ([email protected], [email protected], [email protected], >> [email protected], [email protected], [email protected], [email protected], >> [email protected], [email protected], [email protected], [email protected], >> [email protected], [email protected], [email protected], [email protected], >> [email protected]) >> npm ERR! Linux 3.19.0-65-generic >> npm ERR! argv "/usr/bin/node" "/usr/bin/npm" "install" "--production" >> npm ERR! node v4.2.6 >> npm ERR! npm v2.14.12 >> >> npm ERR! Callback called more than once. >> npm ERR! >> npm ERR! If you need help, you may report this error at: >> npm ERR! <https://github.com/npm/npm/issues> >> >> npm ERR! Please include the following file with any support request: >> npm ERR! /usr/src/couchdb-checkout/src/fauxton/npm-debug.log >> >> I've seen tell of some retry scripts on GH, is this something we could >> consider for the build process? >> -------------------------- >> >> >> >> The rest of the failures are in our test suite. 4 are in eunit and 1 is >> in the JavaScript suite. Here's what I've seen: >> >> >> -------------------------- >> module 'couch_log_writer_syslog_test' >> couch_log_writer_syslog_test: couch_log_writer_syslog_test_...*timed >> out* >> undefined >> >> Not sure why this times out, can we increase the timeout maybe? >> >> >> -------------------------- >> module 'couchdb_compaction_daemon_tests' >> Compaction daemon tests >> couchdb_compaction_daemon_tests:65: should_compact_by_default_rule...*timed >> out* >> undefined >> couchdb_compaction_daemon_tests:99: should_compact_by_dbname_rule...*timed >> out* >> undefined >> >> Same as before, don't know why we time out, can we increase it? >> >> >> -------------------------- >> module 'couchdb_compaction_daemon_tests' >> Compaction daemon tests >> couchdb_compaction_daemon_tests:65: should_compact_by_default_ >> rule...*failed* >> in function >> couchdb_compaction_daemon_tests:'-should_compact_by_default_rule/1-fun-2-'/1 >> (test/couchdb_compaction_daemon_tests.erl, line 88) >> in call from >> couchdb_compaction_daemon_tests:'-should_compact_by_default_rule/1-fun-7-'/1 >> (test/couchdb_compaction_daemon_tests.erl, line 88) >> **error:{assert,[{module,couchdb_compaction_daemon_tests}, >> {line,88}, >> {expression,"DbFrag2 < 70"}, >> {expected,true}, >> {value,false}]} >> output:<<"">> >> >> Paul Davis (davisp) thinks he has fixed this in the pluggable storage >> engine branch. Paul can you confirm? >> >> >> -------------------------- >> module 'couch_log_config_listener_test' >> couch_log_config_listener_test: couch_log_config_test_...*failed* >> in function >> couch_log_config_listener_test:'-check_restart_listener/0-fun-2-'/1 >> (test/couch_log_config_listener_test.erl, line 38) >> in call from couch_log_config_listener_test:check_restart_listener/0 >> (test/couch_log_config_listener_test.erl, line 38) >> **error:{assertEqual,[{module,couch_log_config_listener_test}, >> {line,38}, >> {expression,"get_handler ( )"}, >> {expected,not_found}, >> {value,{config_listener,{couch_log_sup,<0.3192.0>}}}]} >> output:<<"">> >> >> No clue what's going on here. >> >> >> -------------------------- >> test/javascript/tests/replication.js >> Error: expected '5', got '6' >> Trace back (most recent call first): >> >> 52: test/javascript/test_setup.js >> T(false,"expected '5', got '6'",(void 0)) >> 321: test/javascript/couch_test_runner.js >> TEquals(5,6) >> 1620: test/javascript/tests/replication.js >> () >> 37: test/javascript/cli_runner.js >> runTest() >> 48: test/javascript/cli_runner.js >> >> fail >> >> >> Need help analyzing this one. >> >> >> Thanks in advance to anyone who's able to help out here. >> >> -Joan >> -- Professional Support for Apache CouchDB: https://neighbourhood.ie/couchdb-support/ -- Professional Support for Apache CouchDB: https://neighbourhood.ie/couchdb-support/
