Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    James Earl Douglas
    @earldouglas
    rorygraves: Excellent, thanks!
    Grzegorz Slowikowski
    @gslowikowski
    Hi devs.
    Travis build fails since some time due to wrong source code formatting. Can you fix it?
    Ghost
    @ghost~540393fe163965c9bc2018ce
    That's intentional for PRs. Do you mean master?
    Grzegorz Slowikowski
    @gslowikowski
    Master, check the link.
    Ghost
    @ghost~540393fe163965c9bc2018ce
    I'm on a phone, it doesn't render it very well. I'm guessing it's a scalariform regression
    Grzegorz Slowikowski
    @gslowikowski
    Yes
    Nitay Joffe
    @nitay
    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?
    Niklas HH
    @drhumlen
    [info] Repository = ./.git
    org.eclipse.jgit.api.errors.NoHeadException: No HEAD exists and no explicit starting revision was specified
            at org.eclipse.jgit.api.LogCommand.call(LogCommand.java:148)
            at org.scoverage.coveralls.GitClient.lastCommit(GitClient.scala:41)
    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
    Niklas HH
    @drhumlen
    Perhaps I could specify where the git root is somehow; like: coverallGitRoot = file("..") ?
    Or set up a symlink? :S Very hacky, but desperate times calls for desperate measures. Problem is it will probably confuse the real git
    Ryan Williams
    @ryan-williams

    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?

    Ryan Williams
    @ryan-williams
    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
    Grzegorz Slowikowski
    @gslowikowski
    @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.
    Ryan Williams
    @ryan-williams
    interesting, gtk! i am experimenting with using codecov instead of coveralls and so far that's going well
    Pawel Dolega
    @pdolega_twitter
    hi @gslowikowski - any chances there would be new version released anytime soon ? especially with this fix: scoverage/sbt-coveralls#110
    Grzegorz Slowikowski
    @gslowikowski
    Hi @pdolega_twitter . I've merged your PR and 1.2.3 version release process is in progress.
    pdolega
    @pdolega
    Great
    Pascal Mengelt
    @pme123

    I tried with:
    addSbtPlugin("org.scoverage" % "sbt-scoverage" % "1.5.1")
    addSbtPlugin("org.scoverage" % "sbt-coveralls" % "1.2.3")

    But still the same problem like described here: scoverage/sbt-coveralls#104

    pdolega
    @pdolega
    right, but you need "1.2.3" with my chagnes on this PR
    (so basically take changes from my fork, publish it locally - it would be 1.2.4-SNAPSHOT - and then change addSbtPlugin to 1.2.4-SNAPSHOT)
    @pme123 is this what you did ^^ ?
    Pascal Mengelt
    @pme123

    @pdolega ah no - as I read

    Hi @pdolega_twitter . I've merged your PR and 1.2.3 version release process is in progress.

    and was assuming that was it - sorry.

    As I use this with Travis, is there a change that there will be soon a version 1.2.4 available?

    pdolega
    @pdolega
    I guess that's a question to @gslowikowski (i am not a maintainer of the project and don't have any privileges)
    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
    Grzegorz Slowikowski
    @gslowikowski
    @pme123 , I've merged scoverage/sbt-coveralls#110, not #104 (working on it now)
    Pascal Mengelt
    @pme123
    @gslowikowski , I saw #104 was merged - will there be a new release for that change?
    Grzegorz Slowikowski
    @gslowikowski
    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 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.
    pdolega
    @pdolega

    I can take a look and try to reproduce but I am squeezed this week; should have some time next Wed

    Not sure if that helps

    Grzegorz Slowikowski
    @gslowikowski
    OK
    Pascal Mengelt
    @pme123
    @gslowikowski , I tried the snapshot, see the results here: https://travis-ci.org/pme123/scala-adapters/builds/364949832
    Grzegorz Slowikowski
    @gslowikowski
    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.
    Grzegorz Slowikowski
    @gslowikowski
    I've implemented most of the fixes I wanted to and publisted new 1.2.4-SNAPSHOT. @pme123 please rerun the build.
    Pascal Mengelt
    @pme123
    @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
    Grzegorz Slowikowski
    @gslowikowski
    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.
    pdolega
    @pdolega
    :clap:
    Grzegorz Slowikowski
    @gslowikowski
    Version 1.2.5 released. Most important improvements: #119 and #120
    Grzegorz Slowikowski
    @gslowikowski
    Dimitar Georgiev
    @dimitarg

    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
    Dimitar Georgiev
    @dimitarg
    I saw there is a JSON file getting generated, I'll try saving that as a build artifact and inspecting it
    Dimitar Georgiev
    @dimitarg
    Posting here for posterity. The issue was that CI_PULL_REQUEST is a url, and coveralls app was expecting a pull request number. They've went ahead and fixed that, and I'm able to get comments on PRs now.
    sken
    @sken77
    is there a guide for integration with circle?
    sken
    @sken77
    also if i have core and a separate project called testkit how can i tell coverage what tests to use?