Coveralls CI run fails for PRs from forks

[holgerd77]

When a PR is done from a fork, coveralls is failing with:

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

at the end of the state test run, see e.g. #352.

[holgerd77]

@jwasinger Can you have a look at this? I am a bit at the end of my wisdom here and this is really annoying.

[holgerd77]

Have removed coveralls from being required as a PR merge check until we fix this.

[axic]

You need to log in to coveralls, get the repo key and insert that into either the circle.yaml and fill out the setting on the circleci settings page.

See https://docs.coveralls.io/supported-ci-services

[holgerd77]

I think I have done that (going to Coveralls EthereumJS VM settings page, copy the repo token, add it to CircleCI VM settings environment variables) and have just checked, would assume that I have done it correctly. Could you maybe x-check? Maybe I am missing something here.

This is actually working for PRs from this repo itself, just not for forks.

[whymarrh]

This is because Circle CI doesn't pass environment variables to builds started from forks. There's an option to enable it (which would make everything work) but that's probably best left off.

Pass secrets to builds from forked pull requests

Both the Circle CI docs and the Coverall docs are a bit lacking here. The link in the Circle CI settings [1] is broken (maybe it should be this one [2]) but it's clear that we don't want to enable that anyway. The Coveralls docs are unclear about how this should work. They are clear that it should be secret:

The option repo_token (found on your repository’s page on Coveralls) is used to specify which project on Coveralls your project maps to. This is only needed for private repos and should be kept secret – anyone could use it to submit coverage data on your repo’s behalf.

— Coveralls Currently Supports These CIs

My guess here is that fork builds only really "work" from Travis CI and that the only workaround available would be to expose our COVERALLS_REPO_TOKEN .

[holgerd77]

Thanks for the great analysis! However this leaves me puzzled, this is such a common functionality need, isn't it? :-/

[whymarrh]

It is and there are many open discussion on GitHub and Circle CI's forums about it. MetaMask, for example, doesn't bother running Coveralls on fork builds with a check for the env before uploading.