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

[casperdcl]

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 (https://github.com/casperdcl/git-fame/commit/20b3f10f084d4f176ce041c7ec7abd1fa948fa3a)

 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]

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]

I worked around the issue like this: https://github.com/linux-system-roles/tox-lsr/pull/7

[casperdcl]

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]

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]

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

[richm]

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]

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

[richm]

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]

(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]

(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]

[TheKevJames]

@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).