Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Could not submit coverage: 422 Client Error despite defining COVERALLS_REPO_TOKEN on GHA #240

Closed
casperdcl opened this issue Nov 11, 2020 · 12 comments

Comments

@casperdcl
Copy link

casperdcl commented Nov 11, 2020

Despite $COVERALLS_REPO_TOKEN being correctly defined and passed in (via tox), getting a 422 error on GitHub Actions https://github.com/casperdcl/git-fame/runs/1383075434?check_suite_focus=true#step:5:62 (casperdcl/git-fame@20b3f10)

 Could not submit coverage: 422 Client Error: Unprocessable Entity for url: coveralls.io/api/v1/jobs

Note that codecov by comparison (using $CODECOV_TOKEN) works fine.

@richm
Copy link

richm commented Dec 9, 2020

The payload sent to coveralls.io from a Github Actions job must contain {"service_job_id":null, "service_name": "github"}. By default, the coveralls library omits service_job_id and uses github-actions.

@richm
Copy link

richm commented Dec 9, 2020

I worked around the issue like this: linux-system-roles/tox-lsr#7

@casperdcl
Copy link
Author

Good spot on https://github.com/AndreMiras/coveralls-python-action/blob/develop/src/entrypoint.py#L57-L65

I'm just using @AndreMiras's action for now as it's marginally less painful than hacking a fix

@richm
Copy link

richm commented Dec 9, 2020

I'm just using @AndreMiras's action for now as it's marginally less painful than hacking a fix

I tried using that. It does talk to coveralls.io correctly, but it does not read the paths from the .coverage file correctly. It seems the paths are absolute paths in the file e.g. /path/to/src/pkgname/file.py - but that action runs in a container which does a volume map to a different path e.g. docker run ... -v /path/to/src:/path/inside/container - so when the coveralls library goes to read the files, it says "source/path/to/src/pkgname/file.py not found" - it can't find /path/to/src/pkgname/file.py in the container because it has been mapped to /path/inside/container

Perhaps this is a side effect of how I run pytest-cov? Maybe there is a way to generate relative paths in the .coverage file?

@casperdcl
Copy link
Author

@richm
Copy link

richm commented Dec 9, 2020

I think you mean https://coverage.readthedocs.io/en/coverage-5.0.4/config.html#paths

That's better. I can see that my .coverage is being generated with relative paths: https://github.com/linux-system-roles/tox-lsr/pull/7/checks?check_run_id=1525189232

$ strings .coverage
...
5src/tox_lsr/hooks.py
9src/tox_lsr/version.py
...

and the action is able to send a report to coveralls.io. However, the report is wrong: https://coveralls.io/jobs/71961347 - it says 0% coverage, but the output of the run says otherwise:

----------- coverage: platform linux, python 3.8.6-final-0 -----------
Name                      Stmts   Miss  Cover   Missing
-------------------------------------------------------
src/tox_lsr/__init__.py       2      0   100%
src/tox_lsr/hooks.py        155      2    99%   195-198
src/tox_lsr/version.py        2      0   100%
-------------------------------------------------------
TOTAL                       159      2    99%

So there is still something wrong, and running coveralls-python-action with debug: true is not giving me enough clues :-(

@casperdcl
Copy link
Author

casperdcl commented Dec 9, 2020

maybe you need to run coverage xml (or add the flag --cov-report=xml to pytest) to generate a coverage.xml before uploading?

@richm
Copy link

richm commented Dec 9, 2020

maybe you need to run coverage xml (or add the flag --cov=xml to pytest) to generate a coverage.xml before uploading?

So instead of pytest-cov creating a .coverage file in sqlite format, it would create a coverage.xml in xml format?

@casperdcl
Copy link
Author

(I meant --cov-report=xml not --cov=xml) and no, it'll convert the sqlite to xml. Not sure if it'll fix your problem, but I've found sometimes that tools expect/prefer the xml coverage format.

@richm
Copy link

richm commented Dec 9, 2020

(I meant --cov-report=xml not --cov=xml) and no, it'll convert the sqlite to xml. Not sure if it'll fix your problem, but I've found sometimes that tools expect/prefer the xml coverage format.

so coveralls-python-action needs the file .coveragerc in the current directory which has the following:

[run]
relative_files = True

otherwise I guess it doesn't know that the files in .coverage are relative? Anyway, so far it seems to be working.

I suppose most ordinary folks would already have that, but I happen to be in the extraordinary position of having to support py26 for a few customers, and relative_files was added in coverage v5, and coverage v5 doesn't seem to be supported on py26, so I can't have a .coveragerc file with relative_files or it breaks py26, so I have to jump through a few hoops to ensure that the file .coveragerc exists for coveralls-python-action but not for py26 :-(

@casperdcl
Copy link
Author

https://xkcd.com/1739

@TheKevJames
Copy link
Owner

@casperdcl I have set service_job_id to null by default in v3 -- please upgrade and let me know if that works for you! As per @richm 's comment, you may also need to vary the service name (Github Actions seems to be oddly picky about this); with v3, you can set the name explicitly if need be (eg. by doing one of export COVERALLS_SERVICE_NAME=github, adding service_name: github to your yaml config file, or passing --service-name=github on the CLI).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants