Git Error When Sending Coverage Report

[eiskalteschatten]

node.js Version (2.5.x / etc)

12.12.0 and 12.13.0

Operating System (Ubuntu 15.10 / MacOS 10.10 / Windows 10)

macOS 10.15

Testing framework

Jest

Expected Behavior

1. Tests run and generate an LCov coverage report.
2. The coverage report is sent to Codacy.

Actual Behavior

Locally, it works just fine. I am able to run my tests and send the coverage report to Codacy without a problem, but on the server I get an inexplicable error that I have no idea how to solve. The following is the log output with the --debug flag set:

[info] "2019-10-22T08:34:58.607Z"  'Started with: token [undefined], accountToken [undefined], username [undefined], projectName [undefined], commitId [undefined], language [undefined], endpoint [undefined], format [undefined], path prefix ["."], verbose [undefined], debug [true]'
[trace] "2019-10-22T08:34:58.611Z"  'Got chunk'
[trace] "2019-10-22T08:34:58.613Z"  'Received file through stdin'
[info] "2019-10-22T08:34:58.613Z"  'Handling input for: token ["TOKEN REDACTED"], accountToken [undefined], username [undefined], projectName [undefined], commitId [undefined], language [undefined], endpoint [undefined], format ["lcov"], path prefix ["."], verbose [undefined], debug [true]'
[debug] "2019-10-22T08:34:58.616Z"  'Parsing Lcov Data'
[trace] "2019-10-22T08:34:58.649Z"  'Successfully parsed /app/src/app.ts'
... (all files successfully parsed)
[debug] "2019-10-22T08:34:58.664Z"  'Successfully Parsed Lcov Data'
[error] "2019-10-22T08:34:58.670Z"  'Error sending coverage'
[error] "2019-10-22T08:34:58.671Z"  Error: Command failed: git rev-parse HEAD
fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
    at ChildProcess.exithandler (child_process.js:295:12)
    at ChildProcess.emit (events.js:210:5)
    at maybeClose (internal/child_process.js:1021:16)
    at Socket.<anonymous> (internal/child_process.js:430:11)
    at Socket.emit (events.js:210:5)
    at Pipe.<anonymous> (net.js:658:12) {
  killed: false,
  code: 128,
  signal: null,
  cmd: 'git rev-parse HEAD'
}

This is the command I used to run it:

cat ./test-coverage/lcov.info | codacy-coverage -p . --debug

I've tried it both with and without the -p flag.

Why would it try to do anything with git?!

[ljmf00]

Hi @eiskalteschatten ,

In this tool, git is used as a default, when we can't find the environment variable related to the commit hash you are analyzing. Please make sure you are running the reporter in the same directory as your project working directory.

You can also specify manually the commit hash with --commit [value].

Thanks,
Luís

[eiskalteschatten]

Hi @ljmf00 ,

It is run in the project's working directory, but I think the problem is that our CI server runs it in a Docker container that doesn't have git installed. If git is required, then I won't be able to use it unfortunately...

[ljmf00]

Hi @eiskalteschatten ,

It is run in the project's working directory, but I think the problem is that our CI server runs it in a Docker container that doesn't have git installed.

Apparently, according to the logs, you have git, because the stdout of the child process returns a git error fatal: not a git repository . You might not have the .git directory.

If git is required, then I won't be able to use it unfortunately...

If your CI has an environment variable for the commit hash, pass it to the docker, and call the reporter with --commit "$COMMIT_SHA". If you don't have it, you can create the environment variable by yourself using the git command to get the HEAD commit hash: git rev-parse HEAD .

Thanks,
Luís

[eiskalteschatten]

Hi @ljmf00 ,

Apparently, according to the logs, you have git

True, that is a good point. I had a look at the Docker container and git is actually installed. I assumed wrong then.

I talked to our DevOps guy. Apparently when the Docker image is built, he removes the .git folder from the project so that the images will stay as small as possible. Now that he knows git is also in the Docker images, he's going to remove it as well... so now we've moved a step backwards.

I guess I'll just have to find another way such as uploading the coverage report by hand every once in a while from my local machine. Too bad though...

I'll close the issue since it's now an internal issue for us. Thanks for your help though!