Thanks Garren and Jan. Seems the ansible role picks up 4.x by default. I've overridden that to 6.x. That brings with it node 6.10.1 and npm 3.10.10 today. New CI images will be pushed later today.
BTW it's important to note that we'll have trouble running node 7.x on older OSes: https://github.com/nodesource/distributions/blob/master/OLDER_DISTROS.md so please let me know if there is any move towards Fauxton *requiring* that new of a version of node (or npm that needs that version of node) to function. -Joan ----- Original Message ----- > From: "Garren Smith" <gar...@apache.org> > To: dev@couchdb.apache.org > Sent: Tuesday, March 21, 2017 12:26:29 PM > Subject: Re: Stabilizing our automated builds - help needed! > > Oops, well spotted Jan > Upgrading to node 6 should fix this > > > On Tue, 21 Mar 2017 at 4:07 PM Jan Lehnardt <j...@apache.org> wrote: > > > 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 <gar...@apache.org> 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 <woh...@apache.org> > > > 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: > > >> > > >> -------------------------- > > >> grunt-couchapp@0.2.1 node_modules/grunt-couchapp > > >> ├── nano@3.3.0 (errs@0.2.4, request@2.9.203, follow@0.8.0) > > >> ├── couchapp@0.10.0 (watch@0.8.0, coffee-script@1.12.4, > > >> connect@3.6.0) > > >> └── grunt@0.3.17 (dateformat@1.0.2-1.2.3, semver@1.0.14, > > >> async@0.1.22, > > >> colors@0.6.2, hooker@0.2.3, underscore@1.2.4, nopt@1.0.10, > > >> underscore.string@2.1.1, gzip-js@0.3.2, temporary@0.0.8, > > uglify-js@1.3.5, > > >> prompt@0.1.12, glob-whatev@0.1.8, jshint@0.9.1, connect@2.4.6, > > >> nodeunit@0.7.4) > > >> 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/ > > > > >
