Build fails when Coveralls API response is not in expected format

[ruleant]

Sometimes a build on Travis CI fails, I guess because the response of Coveralls API, is not in the expected format.

A more elaborate error message, instead of the thrown ProcessingException, might be useful, fe. 'Coveralls API was unresponsive', or showing/logging the coveralls response, for future debugging?

Some more info on the failure : Building, testing, code coverage goes well, but transfering the result to coveralls fails : BTW : this test was run on my own box, not on Travis CI (hence the repository token), to get some more debug info, file paths have been obfuscated.

[...] [INFO] Cobertura Report generation was successful. [...] [INFO] --- coveralls-maven-plugin:2.1.0:cobertura (default-cli) @ getback_gps --- [INFO] Starting Coveralls job [INFO] Using repository token [INFO] Git commit 44a49e9 in master [INFO] Writing Coveralls data to [HOME]/target/coveralls.json from coverage report [HOME]/target/site/cobertura/coverage.xml [INFO] Successfully wrote Coveralls data in 482ms [INFO] Gathered code coverage metrics for 23 source files with 5157 lines of code: [INFO] - 1123 relevant lines [INFO] - 276 covered lines [INFO] - 847 missed lines [INFO] Submitting Coveralls data to API [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE

Caused by: org.eluder.coveralls.maven.plugin.ProcessingException: com.fasterxml.jackson.core.JsonParseException: Unexpected character ('<' (code 60)): expected a valid value (number, String, array, object, 'true', 'false' or 'null') at [Source: java.io.InputStreamReader@489d479b; line: 1, column: 2] at org.eluder.coveralls.maven.plugin.httpclient.CoverallsClient.parseResponse(CoverallsClient.java:99) at org.eluder.coveralls.maven.plugin.httpclient.CoverallsClient.submit(CoverallsClient.java:89) at org.eluder.coveralls.maven.plugin.AbstractCoverallsMojo.submitData(AbstractCoverallsMojo.java:300) at org.eluder.coveralls.maven.plugin.AbstractCoverallsMojo.execute(AbstractCoverallsMojo.java:184) ... 21 more Caused by: com.fasterxml.jackson.core.JsonParseException: Unexpected character ('<' (code 60)): expected a valid value (number, String, array, object, 'true', 'false' or 'null') at [Source: java.io.InputStreamReader@489d479b; line: 1, column: 2]

[trautonen]

@ruleant thanks for the heads up. I improved the Coveralls API handling even though their error responses are not that great either.

Can you reproduce the issue with some data or is the failure more random? I've never experienced such issue myself. Can you try with the latest snapshot 2.2.0-SNAPSHOT from Sonatype's repository to see what the API actually responds?

[ruleant]

@trautonen Thanks for the quick response.

It happens at random, I guess it has something to do with unresponsiveness of the coveralls API. Last them when it failed on travis, it also failed when I tried to run it on my machine. But since then it ran without trouble. If it happens again, I'll let you know.

I'll start using the 2.2.0-SNAPSHOT, after I figure out how to point to the sonatype repo (I'm new to maven)

[trautonen]

All you need to do is to add the sonatype repository in repositories section of your pom.xml:

<repositories>
  <repository>
    <id>sonatype-nexus-snapshots</id>
    <name>Sonatype Nexus Snapshots</name>
    <url>https://oss.sonatype.org/content/repositories/snapshots</url>
    <releases>
      <enabled>false</enabled>
    </releases>
    <snapshots>
      <enabled>true</enabled>
    </snapshots>
  </repository>
</repositories>

[ruleant]

Thanks. With your example didn't work at first, but with <pluginRepositories> it does.

I'm building now with 2.2.0-SNAPSHOT on Travis, I'll keep you posted.

[trautonen]

Oh you are absolutely right. Forgot pluginRepositories needed different section.

[ruleant]

It happened again, see last few lines of the logfile

First an ERROR message :

[ERROR] Submission failed in 30975ms while processing data

and at the end :

Processing of input or output data failed: Report submission to Coveralls API failed with HTTP status 503: Service Unavailable

BTW : I'm using version 2.2.0-SNAPSHOT

[trautonen]

Usually 503 status comes from load balancer or similar when there are no servers available or there is no more capacity to handle the requests. There's not much that can be done when the service fails this way. Retrying the request is only way, but probably the service is not available when the retry is triggered, so it's not worth it. Only thing we can do is wait and hope Coveralls gets their backend more stable. I think the usage is beyond what they expected, and I saw some post that they are doing a massive rewrite for the backend.

[ruleant]

Let's hope that the coveralls rewrite is launched soon. :)

Thanks for looking into it.

[trautonen]

Improved error messages will be released with v2.2.0.