Coveralls is returning 422 Unprocessable Entity

[afn]

Running rake coveralls:push from Travis shows a 422 error with the following body:

{"message":"Couldn't find a repository matching this job.","error":true}

Nothing changed on our end.

I regenerated the Coveralls token (and updated .coveralls.yml accordingly); this made no difference.

[dhalperi]

Same bug here. Any insight?

[cmaurer]

@afn @dhalperi
I had the same problem with Travis-CI and JavaScript, and I was able to get around it by using environment variables rather than using the .coveralls.yml.

  - export COVERALLS_SERVICE_NAME=travis-ci
  - export COVERALLS_REPO_TOKEN=abc12345

[renan]

I am having the same issue with Private Repositories on Travis-Pro.

I had an existing repository, which was already sending reports to coveralls, re-run a build and it failed to send data. Added a new repository, same issue.

[dhalperi]

@cmaurer that approach did not work with travis-pro.

[nickmerwin]

Hi all we're looking into this issue now!

[nickmerwin]

Ok, found the cause, Travis-Pro rolled all of their API tokens for heartbleed; I've done the same on our side. Please log in again to Coveralls to make sure we have a valid Github token, then the next job that we process will update our Travis-Pro token.

Thank you everyone for your patience!

[dhalperi]

Worked! Thanks @nickmerwin

[renan]

Thanks! 👍

[charliequinn]

Hi guys,

I'm still seeing this issue (on travis-pro)

• I deleted my existing repo from coveralls (only signed up yesterday)
• Added it again
• updated .coveralls.yml with service_name and new repo_token value

still returns 422.

If I don't set service_name then it does update the coveralls repo with my coverage stats, however, it seems to find the build information for a random travis-ci job.

Any help would be greatly appreciated. Am I missing something?

[nickmerwin]

@charliequinn hi, could you send me the name of the repo on which this is occurring here: support@coveralls.io ?

[charliequinn]

Thanks Nick

I've sent the name of the repo, plus json sent and response to support.

[thoutbeckers]

Seems like we have this issue when a fork of our private repo is built, if that helps. These don't normally get built by Travis, but they do in case of a pull request.

edit: this is because Travis doesn't expose secure tokens on a PR build.