Error on Travis after update

[vernak2539]

I've updated to coveralls 2.11.x, using node 0.10.35. On TravisCI I get the error below. All my tests pass, but the coveralls portion makes the build fail.

Build

=============================================================================
Writing coverage object [/home/travis/build/vernak2539/express-less-middleware/coverage/coverage.json]
Writing coverage reports at [/home/travis/build/vernak2539/express-less-middleware/coverage]
=============================================================================
=============================== Coverage summary ===============================
Statements   : 100% ( 74/74 )
Branches     : 93.33% ( 28/30 )
Functions    : 100% ( 17/17 )
Lines        : 100% ( 74/74 )
================================================================================
[error] "2015-03-09T15:40:36.429Z"  'error from getOptions'
/home/travis/build/vernak2539/express-less-middleware/node_modules/coveralls/bin/coveralls.js:18
        throw err;
              ^
Error: Command failed: fatal: Not a valid object name 5460d7ffca633a2769e4b43b38491faf0caed912
    at ChildProcess.exithandler (child_process.js:658:15)
    at ChildProcess.emit (events.js:98:17)
    at maybeClose (child_process.js:766:16)
    at Socket.<anonymous> (child_process.js:979:11)
    at Socket.emit (events.js:95:17)
    at Pipe.close (net.js:466:12)
npm ERR! Test failed.  See above for more details.
npm ERR! not ok code 0

[elicwhite]

I'm getting this as well, but it is inconsistent. It is happening about 1/6 runs, which means that my builds are marked as failed about half of the time. I can rerun the build to get this to work, but flaky tests are about as good as no tests. :-/

=============================================================================
Writing coverage object [/home/travis/build/VisualTesting/api/coverage/coverage.json]
Writing coverage reports at [/home/travis/build/VisualTesting/api/coverage]
=============================================================================
=============================== Coverage summary ===============================
Statements   : 92.94% ( 316/340 )
Branches     : 78.18% ( 43/55 )
Functions    : 89.72% ( 96/107 )
Lines        : 92.94% ( 316/340 )
================================================================================
[error] "2015-03-12T07:01:06.396Z"  'error from getOptions'
/home/travis/build/VisualTesting/api/node_modules/coveralls/bin/coveralls.js:18
        throw err;
              ^
Error: Command failed: /bin/sh -c git cat-file -p b63c404d815062785b39cec8c39db84bff16cc4d
fatal: Not a valid object name b63c404d815062785b39cec8c39db84bff16cc4d
    at ChildProcess.exithandler (child_process.js:744:12)
    at ChildProcess.emit (events.js:110:17)
    at maybeClose (child_process.js:1008:16)
    at Socket.<anonymous> (child_process.js:1176:11)
    at Socket.emit (events.js:107:17)
    at Pipe.close (net.js:476:12)
npm ERR! Linux 2.6.32-042stab090.5
npm ERR! argv "/home/travis/.nvm/versions/node/v0.12.0/bin/node" "/home/travis/.nvm/versions/node/v0.12.0/bin/npm" "run" "travis"
npm ERR! node v0.12.0
npm ERR! npm  v2.5.1
npm ERR! code ELIFECYCLE
npm ERR! visualtesting-api@0.0.0 travis: `NODE_ENV=test istanbul cover ./node_modules/mocha/bin/_mocha --report lcovonly -- -R spec && cat ./coverage/lcov.info | coveralls && rm -rf ./coverage`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the visualtesting-api@0.0.0 travis script 'NODE_ENV=test istanbul cover ./node_modules/mocha/bin/_mocha --report lcovonly -- -R spec && cat ./coverage/lcov.info | coveralls && rm -rf ./coverage'.
npm ERR! This is most likely a problem with the visualtesting-api package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     NODE_ENV=test istanbul cover ./node_modules/mocha/bin/_mocha --report lcovonly -- -R spec && cat ./coverage/lcov.info | coveralls && rm -rf ./coverage
npm ERR! You can get their info via:
npm ERR!     npm owner ls visualtesting-api
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     /home/travis/build/VisualTesting/api/npm-debug.log
The command "npm run travis" exited with 1.
Done. Your build exited with 1.

[sanemat]

same error(?) with iojs v1.5.1

[error] "2015-03-18T20:45:35.696Z"  'error from lcovParse: ' 'Failed to parse string'
[error] "2015-03-18T20:45:35.700Z"  'input: ' ''
[error] "2015-03-18T20:45:35.701Z"  'error from convertLcovToCoveralls'

/home/travis/build/sanemat/nwjs-nico-player/node_modules/coveralls/bin/coveralls.js:18
        throw err;
              ^
Failed to parse string

npm ERR! Linux 2.6.32-042stab090.5
npm ERR! argv "/home/travis/.nvm/versions/io.js/v1.5.1/bin/iojs" "/home/travis/.nvm/versions/io.js/v1.5.1/bin/npm" "run" "coveralls"
npm ERR! node v1.5.1
npm ERR! npm  v2.7.0
npm ERR! code ELIFECYCLE
npm ERR! nico-player@0.0.0 coveralls: `gulp test && cat coverage/lcov.info | ./node_modules/coveralls/bin/coveralls.js`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the nico-player@0.0.0 coveralls script 'gulp test && cat coverage/lcov.info | ./node_modules/coveralls/bin/coveralls.js'.
npm ERR! This is most likely a problem with the nico-player package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     gulp test && cat coverage/lcov.info | ./node_modules/coveralls/bin/coveralls.js
npm ERR! You can get their info via:
npm ERR!     npm owner ls nico-player
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /home/travis/build/sanemat/nwjs-nico-player/npm-debug.log

Done. Your build exited with 0.

[arboleya]

Any news on this?

[thepian]

Seeing it as well. nodejs passes, iojs fails.

[danvk]

I'm also seeing this. Here are a few sample builds:

https://travis-ci.org/danvk/dygraphs/builds/59422747 https://travis-ci.org/danvk/dygraphs/builds/59428362 https://travis-ci.org/danvk/dygraphs/builds/59422948

[thepian]

Any progress on this?

https://travis-ci.org/socketstream/socketstream/jobs/66765247

[vladikoff]

[error] "2015-07-27T14:24:17.323Z"  'error from getOptions'
r/node_modules/coveralls/bin/coveralls.js:18
        throw err;
              ^
Error: Command failed: fatal: Not a valid object name 28f590a413ff15b817b66e26f844e77678aff2e5
    at ChildProcess.exithandler (child_process.js:658:15)
    at ChildProcess.emit (events.js:98:17)
    at maybeClose (child_process.js:766:16)
    at Process.ChildProcess._handle.onexit (child_process.js:833:5)

Is this related?

[daleharvey]

I got this recently and did notice the offending PR had a merge conflict, not entirely sure how that would cause this but just in case

[daleharvey]

Yup seeing this pretty regularly these days, always seems to be PR's that are not caught up to master - https://github.com/pouchdb/pouchdb/issues/4142

Possibly worth mentioning we do a shallow clone - https://github.com/pouchdb/pouchdb/blob/master/.travis.yml#L9

[daleharvey]

Ok going to take a look at this, we would like to not regress coverage and this is failing pretty regularly, if anyone has any guidance then it would be useful. Cheers

[daleharvey]

So the checkout that travis is testing is a merge commit of the TRAVIS_COMMIT and latest master, not entirely sure why that means the TRAVIS_COMMIT isnt in the tree anywhere

[daleharvey]

Changing https://github.com/nickmerwin/node-coveralls/blob/master/lib/getOptions.js#L21 to FETCH_HEAD would likely fix this

[vernak2539]

TRAVIS_COMMIT is the commit travis is testing. Can be searched for here --> http://docs.travis-ci.com/user/environment-variables/

[daleharvey]

Its not the commit travis is testing, looking at the logs in the travis run travis does

$ git clone --depth=50 git://github.com/danvk/dygraphs.git danvk/dygraphs
$ cd danvk/dygraphs
$ git fetch origin +refs/pull/590/merge:
$ git checkout -qf FETCH_HEAD

Which means the commit is a merge commit that looks like

$ git cat-file -p FETCH_HEAD
tree 427e79404b73fbf45d1ff036e308b394cf50dd03
parent 963175fa273ae0a214b4ee4f49282ea49922a9d2
parent 8a6e4faae457974eae9258776a9bb7d4bf745b86
author Greenkeeper <support@greenkeeper.io> 1444643060 +0000
committer Greenkeeper <support@greenkeeper.io> 1444643060 +0000

Merge 8a6e4faae457974eae9258776a9bb7d4bf745b86 into 963175fa273ae0a214b4ee4f49282ea49922a9d2

Some how this puts us in a position where TRAVIS_COMMIT may not exist

[vernak2539]

TRAVIS_COMMIT is a specific environment variable that TravisCI uses. FETCH_HEAD is specific to git and fetches . If TRAVIS_COMMIT doesn't exist, then something is wrong with Travis itself, which is a little unlikely.

[daleharvey]

Sorry I did not mean TRAVIS_COMMIT does not exist, but that TRAVIS_COMMIT is a reference to a commit that is not in the current tree which is very definitely happening as these failures are due to

$ git cat-file -p 9a6e4faae457974eae9258776a9bb7d4bf745b86
fatal: Not a valid object name 9a6e4faae457974eae9258776a9bb7d4bf745b86

[daleharvey]

@svenfuchs if you had any guidance here it would be super help, cheers

[daleharvey]

And to explain the problem, node-coveralls is trying to read the commit information via git cat-file -p TRAVIS_COMMIT and failing because that object does not exist in the tree

Travis will run this to checkout a tree:

$ git clone --depth=50 git://github.com/pouchdb/pouchdb.git pouchdb/pouchdb
$ cd pouchdb/pouchdb
$ git fetch origin +refs/pull/4457/merge:
$ git checkout -qf FETCH_HEAD

The git log from this looks like

commit e7fad676d4cb7cbac19e1e4387dd55bb75ec06bc
Merge: 963175f 8a6e4fa
Author: Greenkeeper <support@greenkeeper.io>
Date:   Mon Oct 12 09:44:20 2015 +0000

    Merge 8a6e4faae457974eae9258776a9bb7d4bf745b86 into 963175fa273ae0a214b4ee4f49282ea49922a9d2

commit 963175fa273ae0a214b4ee4f49282ea49922a9d2
Author: greenkeeperio-bot <support@greenkeeper.io>
Date:   Sun Oct 11 17:25:41 2015 +0200

    (#4457) - chore(package): update uglify-js to version 2.5.0

    http://greenkeeper.io/

It will then run a script with TRAVIS_COMMIT=4850505cfa73be24e269ba66b9b41ea76a45a2ae (not sure what that commit is), node-coveralls will attempt to read that commit to get the commit message / author / commit information, that will fail with:

$ git cat-file -p 4850505cfa73be24e269ba66b9b41ea76a45a2ae
fatal: Not a valid object name 4850505cfa73be24e269ba66b9b41ea76a45a2ae

There is an example of this bug @ https://travis-ci.org/pouchdb/pouchdb/jobs/84788081 that was triggered from a PR @ https://github.com/pouchdb/pouchdb/pull/4457

[lijunle]

+1 here, any update on this issue. This is boring. :angry:

[vladikoff]

This is boring. :angry:

Please keep the comments relevant to the issue, thanks

[BanzaiMan]

Hello. @janl asked me to look into this.

As @daleharvey says in the comment above (https://github.com/nickmerwin/node-coveralls/issues/80#issuecomment-147460747) the issue is the discrepancy between FETCH_HEAD and $TRAVIS_COMMIT. I looked at a few things, but I must say that I do not quite understand under what circumstances this discrepancy occurs. (For example, https://travis-ci.org/BanzaiMan/travis_production_test/builds/92979382 shows that FETCH_HEAD and $TRAVIS_COMMIT agree.)

[daleharvey]

I am not entirely certain about this, but I believe the issue seems to happen more when the PR is not based on the latest HEAD

[BanzaiMan]

@daleharvey Ah, that makes sense. I was able to reproduce this now.

[nickmerwin]

Hi @daleharvey and @BanzaiMan, in coveralls-ruby we get the git info using git log -1, e.g.:

message = `git log -1 --pretty=format:'%ce'`

https://github.com/lemurheavy/coveralls-ruby/blob/master/lib/coveralls/configuration.rb#L138

Do you think changing to that would suffice here?

[daleharvey]

That sounds great, being consistent across the different implementations seems like a good thing and that git log definitely shouldnt be able to fail

[coderaiser]

Same error with node v5.8.0:

> nyc report --reporter=text-lcov | coveralls
[error] "2016-03-09T22:42:22.635Z"  'error from lcovParse: ' 'Failed to parse string'
[error] "2016-03-09T22:42:22.639Z"  'input: ' ''
[error] "2016-03-09T22:42:22.640Z"  'error from convertLcovToCoveralls'
/home/travis/build/coderaiser/cloudcmd/node_modules/coveralls/bin/coveralls.js:18
        throw err;
        ^
Failed to parse string

But with node v4.4.0 everything is ok.

[MoOx]

@coderaiser your issue seems different to the one of this thread, but be similar to the one I just got. Related to npm. And can be fixed https://github.com/MoOx/js-boilerplate/pull/2/commits/15f2d22d50fd446968eb472f3f6fd866da8eda0e

[cjpatoilo]

Same error with node v7.2.0 npm v4.0.2:

package.json

  "devDependencies": {
    "ava": "^0.17.0",
    "coveralls": "^2.11.15",
    "nyc": "^10.0.0",
    "standard": "^8.6.0"
  },
  "engines": {
    "node": "^7.0.0"
  },
  "scripts": {
    "test": "standard && nyc ava",
    "coveralls": "nyc report --reporter=text-lcov | coveralls"
  }

Error:

nyc report --reporter=text-lcov | coveralls
[error] "2016-12-01T20:12:44.204Z"  'error from lcovParse: ' 'Failed to parse string'
[error] "2016-12-01T20:12:44.206Z"  'input: ' ''
[error] "2016-12-01T20:12:44.207Z"  'error from convertLcovToCoveralls'
/home/travis/build/cjpatoilo/initify/node_modules/coveralls/bin/coveralls.js:18
        throw err;
        ^
Failed to parse string
npm ERR! Linux 4.8.7-040807-generic
npm ERR! argv "/home/travis/.nvm/versions/node/v7.2.0/bin/node" "/home/travis/.nvm/versions/node/v7.2.0/bin/npm" "run" "coveralls"
npm ERR! node v7.2.0
npm ERR! npm  v4.0.2

[jcheng31]

I'm getting what seems to be the same error here, but using Drone and node v0.12.9 with coveralls 2.11.16.

Error: Command failed: /bin/sh -c git cat-file -p 509a19cf0cb252cfbb30a3b7d9eaae13df51752e
fatal: Not a valid object name 509a19cf0cb252cfbb30a3b7d9eaae13df51752e

    at ChildProcess.exithandler (child_process.js:751:12)
    at ChildProcess.emit (events.js:110:17)
    at maybeClose (child_process.js:1016:16)
    at Socket.<anonymous> (child_process.js:1184:11)
    at Socket.emit (events.js:107:17)
    at Pipe.close (net.js:484:11)

This was from the build triggered by opening a GitHub PR; the one for the commit itself was okay. We're also using shallow clones, and this particular branch is up-to-date with master.

[Maxim-Mazurok]

Same here: https://ci.appveyor.com/project/benmosher/eslint-plugin-import/build/job/082hg6pn86k6dwmt