I'm having trouble getting coveralls to work, and seeing really weird sbt errors. I've followed the readme from github. Here's some example output - https://gist.github.com/nitay/bedaa252279fdde17584226a89456d22
as u can see i've tried both putting the token in the file and in my build file
but i really dont get why e.g. coverallsToken is not even defined?
1 reply
It assumes there's a .git-folder at cwd, but in our project, the build.sbt lies inside a
backend/-folder; so we have to do cd backend && sbt coverageReport coveralls
any suggestions how I can make it not fail?
everything up to that point seems to work
Or set up a symlink? :S Very hacky, but desperate times calls for desperate measures. Problem is it will probably confuse the real
git
this is the line that blows up btw: https://github.com/scoverage/sbt-coveralls/blob/master/src/main/scala/org/scoverage/coveralls/GitClient.scala#L41
Because this line: https://github.com/scoverage/sbt-coveralls/blob/master/src/main/scala/org/scoverage/coveralls/GitClient.scala#L24 always assumes the
.git folder is located at cwd
I have a multi-module SBT project, and some lines from a base module A are tested while running the tests in module B that dependsOn A, but coveralls seems to only know about lines in A that were run during A's tests
does anyone have any insight into how I can collect coverage data about all files in my project when running any of the modules' tests?
seems like coveralls has been down since last night, all of my uploads from TravisCI and local time out like:
…
[info] Aggregation complete. Coverage was [91.82]
[info] All done. Coverage was [91.82%]
[info] Running coveralls
[info] Repository = ./.git
[error] java.net.ConnectException: Connection timed out (Connection timed out)
[error] at java.net.PlainSocketImpl.socketConnect(Native Method)
[error] at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
[error] at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
[error] at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
[error] at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
[error] at java.net.Socket.connect(Socket.java:589)
[error] at java.net.Socket.connect(Socket.java:538)
…
in case anyone else can corroborate/refute
@ryan-williams , recently there are problems with http://cobertura.sourceforge.net/xml/coverage-04.dtd access. Sometimes it is accessible, sometimes it's not. This document is referenced by
cobertura.xml reports used by coveralls plugin.
@pme123 is this what you did ^^ ?
but I guess that the underlying question is:
can we automate SNAPSHOT releases (via travis master builds) - that would sort out such issues in a systematic way
Hi @pme123 . While testing the plugin (I've never used it before) I found two additional problems, one of them serious. The serious one is publishing N times coverage results, where N is a number of modules (including root module) in multimodule project. For example in a project with root and three modules, coverage results are published four times - once per module plus aggregated coverage for root.
I'd like someone to confirm my observations, or not. I see you have multi-module projects (e.g. 'scala-adapters') so maybe you will help me.
I've published
I'd like someone to confirm my observations, or not. I see you have multi-module projects (e.g. 'scala-adapters') so maybe you will help me.
I've published
1.2.4-SNAPSHOT to Sonatype snapshots repo. Add resolvers += Resolver.sonatypeRepo("snapshots") to your build, change plugin version to 1.2.4-SNAPSHOT and push the changes. We will see, if Travis build will succeed.
@gslowikowski , I tried the snapshot, see the results here: https://travis-ci.org/pme123/scala-adapters/builds/364949832
Your project shows the bug I found before, but reports it in very specific way. You are running tests and generating coverage info for two out of four modules (without client and shared.js) and then aggregating. Coveralls checks, if all four modules plus root contain 'coverage.xml' file. It does not make sense and it fails.
@gslowikowski , you did it! Thanks.
No exceptions during the build: https://travis-ci.org/pme123/scala-adapters/builds/365561655
Both JVM projects are listed correctly on Coverall: https://coveralls.io/builds/16479895
No exceptions during the build: https://travis-ci.org/pme123/scala-adapters/builds/365561655
Both JVM projects are listed correctly on Coverall: https://coveralls.io/builds/16479895
Hello. I've just published version
1.2.5-SNAPSHOT with some changes listed here. These are things I found worth improving while I was working on previous version.
Hello folks, I'm using sbt-coveralls with circleci. My builds in Coveralls are not detected as PR builds and consequently I don't get PR comments from coveralls bot.
I can see that the CI_PULL_REQUEST env var is present in my build environment. Also I can see that https://github.com/scoverage/sbt-coveralls/blob/master/src/main/scala/org/scoverage/coveralls/CoverallPayloadWriter.scala#L37 should pick that up. But on the server side my build is listed as 'push`.
Any pointers how can I troubleshoot this further?
I guess I'm looking for some form of verbose logging or such, where I can see what is getting sent to coveralls API
Would it be possible to create a release of sbt-coveralls with the latest version of jackson, i.e. scoverage/sbt-coveralls#179