Report submission to Coveralls API failed with HTTP status 422: Unprocessable Entity (Couldn't find a repository matching this job.

[leerho]

Error message "after_success" from Travis-CI build. This is a conventional Java build process. I have one repo with the identical setup that seems to work and several other, identically configured repos that fail with the above message.

This is the build-log that worked: Travis build for DS-memory for datasketches-memory

This is one example build-log that refuses to work: Travis build for DS-java for datasketches-java

Your "JAVA SET UP FOR COVERALLS" page doesn't make any sense to me.

• I am using standard Travis-CI and it builds fine. I'm not using Travis-Pro so the first code box doesn't apply. Nor should I include the repo token.
• I'm not using a private CI or CL other than Travis Pro, so the 2nd code box doesn't apply AND I should not be including my repo token anyway.
• These repos are for Java, so we don't use Gemfiles and have never in the past had to use Gemfiles for Coveralls. So the 3rd code box should not be required.
• Again these are pretty standard Java repos and has no Ruby anywhere. So I don't have "spec-helper.rb" or "test_helper.rb" files. So the 4th code box doesn't apply.
• Finally, the statement "And that is that! Coverage for your next Travis build should appear here!" is meaningless. I don't want the coverage report on your Coveralls web page, I want it reported under /target and in a badge on the repo GitHub sites.

Please help. I have spent many hours scouring the internet for clues on how to fix this with no luck. I have been using Coveralls for many years, but now, for some reason it refuses to work.

Thanks, Lee.

[afinetooth]

hi @leerho,

here's the next thing to try, and some responses to your questions:

---

next thing to try:

can you please try running your build in debug mode / verbose mode?

i'm not very familiar with coveralls-maven-plugin, but I'm hoping it has a debug mode that adds debug output to the CI stdout, ideally with the JSON that's being packaged up and sent to the coveralls API.

my best guess on how to invoke that is to pass -DisDebugEnabled=true, probably in the line:

mvn clean test jacoco:report coveralls:report -q -DrepoToken=$coveralls_token -DisDebugEnabled=true

based on the refs here, here and here.

that output will help me give more insight.

---

responses:

Your "JAVA SET UP FOR COVERALLS" page doesn't make any sense to me.

it's legacy and needs an update, apologies. we're working on documentation updates that will extend to those start pages.

• Is it possible this is being affected by the migration of travis-ci.org projects to travis-ci.com? i noticed the url of your build is a travis-ci.com url: Travis build for DS-java

when i visit travis-ci-org, i see this warning message, but don't know when it takes effect:

if this is the issue, it could be worth adding a coveralls.yml file with service-name: travis-pro.

you can switch it back to service-name: travis-ci if it doesn't seem to work.

• as jobs from travis-ci.com used to be considered private by default, it's also worth including your coveralls repo token. (it will not hurt in any case.)

you can add this to your .coveralls.yml like the example repo_token: z2NyvKNpclvuc31m2yfZrpzrPr1cnLjSd, or for better security, set the following environment variable at travis:

COVERALLS_REPO_TOKEN= z2NyvKNpclvuc31m2yfZrpzrPr1cnLjSd

i'm hoping coveralls-maven-plugin looks in both places for that. i suspect it does. (it's defined here.)

• yes, you're right, this is irrelevant. an update is needed.

• same as above. we're looking for the analogs in your java setup, which should be covered by your setup for coveralls-maven-plugin.

• i understand. nevertheless, there will always be a coveralls build page for each of your builds. once you set up your badge and/or PR comments/checks, you won't need to look at it.

---

let me know how it goes.

[leerho]

I discovered that the repo that worked did NOT have a Coveralls Token registered. And the repos that were failing had a different Coveralls token, because the name of the repo changed. (We graduated from "incubating-datasketches-java" to just "datasketches-java"). Fixing the token allowed the Coveralls job to run.

Well, a tiny step forward, but I still have "coverage unknown" in the badge even though Coveralls did run and reports 99% coverage on the Coveralls page AND displays the "coverage unknown" badge on that same page! Here are the links:

Github site: github.com/apache/datasketches-java Coverage: unknown

Travis CI Branch Build job: #2337.1 3min, 1 sec /travis-ci.com/github/apache/datasketches-java/jobs/477510739 build exited with 0.

Travis pull Request Build job: #2338 3min, 1 sec travis-ci.com/github/apache/datasketches-java/builds/214979475 build exited with 0.

Coveralls Job: coveralls.io/builds/36660446 Coverage: 99% Badge: "coverage unknown" yet Coveralls reports 99% coverage

Recommended and Actual Markup badge Embed Reference:

This I think may be a Coveralls problem.

[afinetooth]

Great to hear.

This is an easy one: You need a build on master.

In order to populate your coverage badge, or see PR comments/checks against your PR builds, you'll need at least one build on your default branch (in your case, master).

Badge coverage is for the default branch, and PR comments (and checks) require a build on the base branch (base build) to compare to, in order to show changes in coverage.

Right now, you only have two (2) builds on the project, both in update_travis_pom. If you're happy with your setup changes there, merge them into master and you'll start seeing badge coverage and PR comments/checks.

[leerho]

I did merge the update_travis_pom branch into master, and still the coverage=unknown.

This is a very common and safe way to develop code. We create a branch, do all of our changes there, create a PR. If the PR is successful (without errors), we review, then merge. You are saying that this process will not update the coverage? I'm pretty sure it used to work. So I'm puzzled as what changed. We have been using Coveralls for years and this issue is just now showing up.

[afinetooth]

Hi @leerho, perhaps I misunderstand, but I only meant that you would not see PR comments/checks or badge coverage if you were missing your first commit to master.

We do indeed show a coverage percentage for any build on any branch.

And that coverage tracks for all previous builds on the same branch.

You can see that on your PR builds prior to the first merge, ex: https://coveralls.io/builds/36660446

And you can see the change in coverage on that branch by comparing the previous build on that same branch: https://coveralls.io/builds/36660233

It just so happens that in this case, the coverage did not change.

Again, the change is there, but the comparison (to base) is not, until you have at least one build on your default branch.

In any case, looking at your repo I see the last several builds on master and things look good.

Let me know if you don't start seeing PR checks on your next PR.

You won't see PR comments, as I noticed you have them disabled in your settings:

[leerho]

Thank you!

One more request: It turns out that doing the build with Travis-ci takes forever. The last build I did with Travis was in queue for 10 hours. When the job ran it took only 3 minutes. So I want to try GitHub Actions.

I can't find a relevant example of configuring the workflow script for the common configuration: GitHub.Actions for Java / Maven / Coveralls. So this is my best-guess attempt, does this look right?

name: Java CI with Maven, Coveralls

on:
    push:
        branches: [ master ]
    pull_request:
        branches: [ master ]

jobs:
    build:
        runs-on: ubuntu-latest
        env: 
            MAVEN_OPTS="-Xmx4g -Xms1g"
        
        steps:
        - name: Checkout
          uses: actions/checkout@v2

        - name: Set up JDK 1.8
          uses: actions/setup-java@v1
          with:
              java-version: 1.8 

        - name: Maven clean test
          run: mvn clean test jacoco:report coveralls:report -q -Dgpg.skip=true -DisDebugEnabled=true --batch-mode

        - name: Coveralls
          uses: coverallsapp/github-action@master
          with:
              github-token: ${{ secrets.github_token }}

Many, many thanks! Lee.

[leerho]

Also, with this GitHub action, do I remove the coveralls-maven-plugin from the POM? The test data is generated using surefire and jacoco.

[devkapilbansal]

Hi, I tried uploading my lua coverage stats to coveralls but got same error using Github Actions. Any help?

[afinetooth]

Hi @devkapilbansal this could mean that you're using the wrong identifier for the repo given other config settings.

To help further, we'll need to know more about your setup, in particular, which coveralls integration you're using in combination with Github Actions.

If you're using the Coveralls Github Action, you will need to pass {{ secrets.GITHUB_TOKEN }} for repo-token per usage instructions in the README.

Furthermore, if you are using the Coveralls Github Action, you can set the following CI environment variable in your config yaml to put your build logs in verbose mode: NODE_COVERALLS_DEBUG=1

That will display the JSON you're about to post to the Coveralls API and will be the best diagnosis tool to share with us.

If your repo is private or you're concerned about sensitive data, please email us your details at [email protected].

[devkapilbansal]

Thanks @afinetooth. I thought that repo token is one provided by coveralls website. It works now.

[stale[bot]]

This issue has been automatically marked for closure because it has not had recent activity. It will be closed if no further activity occurs. If your issue is still active please add a comment and we’ll review as soon as we can. Thank you for your contributions.