Using python-coveralls from github-actions returns "Could not submit coverage: 422 Client Error"

Question

Coveralls python wrapper (python-coveralls) recently received a major update (2.2.0 -> 3.0.0) and my github-actions workflow is no longer running.

This is the relevant part of my workflow:

  test:
    runs-on: ubuntu-latest
    steps:
    {... non-relevant steps...}
    - name: Run test suite
      run: tox -e $(echo py${{ matrix.python-version }}-mg${{ matrix.PYMONGO }} | tr -d . | sed -e 's/pypypy/pypy/') -- -a "--cov=my_project"
    - name: Send coverage to Coveralls
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      run: coveralls

This used to work with previous version of python-coveralls, so the tox command is not the problem

This is the error I receive:

Submitting coverage to coveralls.io...
Could not submit coverage: 422 Client Error: Unprocessable Entity for url: https://coveralls.io/api/v1/jobs
resubmitting with id None-158455276967659442
Traceback (most recent call last):
  File "/opt/hostedtoolcache/Python/3.7.9/x64/lib/python3.7/site-packages/coveralls/api.py", line 252, in wear
    response.raise_for_status()
  File "/opt/hostedtoolcache/Python/3.7.9/x64/lib/python3.7/site-packages/requests/models.py", line 943, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 422 Client Error: Unprocessable Entity for url: https://coveralls.io/api/v1/jobs

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/hostedtoolcache/Python/3.7.9/x64/lib/python3.7/site-packages/coveralls/cli.py", line 85, in main
    result = coverallz.wear()
  File "/opt/hostedtoolcache/Python/3.7.9/x64/lib/python3.7/site-packages/coveralls/api.py", line 255, in wear
    raise CoverallsException('Could not submit coverage: {}'.format(e))
coveralls.exception.CoverallsException: Could not submit coverage: 422 Client Error: Unprocessable Entity for url: https://coveralls.io/api/v1/jobs

Centum

Answer 1

You could try adding the service name as state in the release notes and mentioned here: https://github.com/coveralls-clients/coveralls-python/issues/251

run: coveralls --service=github

Dragonet

That did the trick, thanks! It's also possible to use COVERALLS_SERVICE_NAME env var but the outcome is the same – Centum

I find the environment variable preferable since it means that you could switch CI providers and you wouldn't need to change the code you've checked into your repo -- you just set the environment variable appropriately on either service. Another benefit is that if you're using a make target to run coverage, e.g. make coverage, then you could run the same target locally on your machine that you run on the CI provider, and both would work because the environment variables would be different and would contain the necessary config to upload to Coveralls in either case. – Chester