Using for Python code and coverage.py

[aodj]

I was just looking into this for use in the GitHub actions beta, and covering my Python code, but it looks like the coverage tooling for Python doesn't support lcov output (ie running coverage.py via pytest-cov on pytest unittests).

I know that the coveralls Python library can interface with the coveralls.io API, so I'm curious what the suggested solution might be.

Any ideas?

[nickmerwin]

Hi @aodj, could you try the steps described here:

https://github.com/coveralls-clients/coveralls-python/blob/master/docs/usage/multilang.rst

e.g.:

coveralls --output=coverage.json
coveralls-lcov -v -n coverage.info > coverage.json

Then use "./coverage.json" as the path-to-lcov input for the Coveralls Action.

Let me know how it goes, thanks!

[aodj]

I'll give it a try, but is installing and running a Ruby gem the only option here? I've previously used a workflow on Travis that simply invokes the coveralls tool which uploads the output from coverage.py, which is nice since it's simply a case of installing an extra Python lib.

[aodj]

I think I'm missing something; the coveralls-lcov tool doesn't output LCOV formatted data. It consumes LCOV data to output json Looking at the coveralls Python library, is it not possible to use the api/v1/jobs endpoint since that appears to consume the more common JSON format instead of LCOV:

[aodj]

Any more thoughts on using the action with Python?

[aodj]

Just to keep this ticket up-to-date I gave up with this action, and just used the coveralls Python package. Workflow for reference.

[mikkokotila]

@aodj dead simple approach solves the issue. Which raises an important question; how come the official version from the company itself, does not work?

[hakonanes]

However, running just coveralls on a pull_request event does not prompt Coveralls.io to later on to add a comment to the PR, even though it is enabled in the Coveralls.io settings?

[abhinavsingh]

This probably should be re-opened or at-least put instructions for Python integration upfront in README.

[jvesely]

Running just coveralls in github actions reports branch HEAD. I ended up with:

    - name: Coveralls
      run: |
        CI_BRANCH=${GITHUB_REF#"ref/heads"} coveralls
      shell: bash

@hakonanes, There's also CI_PULL_REQUEST env var that you can set to something from ${{ github.event }} context or parse it out of the file at $GITHUB_EVENT_PATH

[ly-cultureiq]

if nickmerwin/node-coveralls#243 gets merged - i have a simple pr to add pytest and coverage.py support

[bboe]

For anyone following this issue, I was able to get parallel builds to work with python-coveralls coveralls-python (https://github.com/coveralls-clients/coveralls-python) and using this action just for the parallel-finish step.

See my workflow modification here: praw-dev/prawtools@bb0e00b

Note getting this to work does depend on the changes here: https://github.com/coveralls-clients/coveralls-python/pull/216/files

Edit: thanks for the correction @agonholm

[agronholm]

Just to un-confused others reading this: @bboe did not actually use python-coveralls (which is a separate client for coveralls.io), but a modified version of coveralls-python (available as coveralls on the PyPI).

This combination worked for me too. Let's hope the PR gets merged.

[agronholm]

@bboe has your PR actually been merged? I tried with coveralls 2.0.0 and, unlike your version, it didn't work without using the coveralls token instead of the github token due to the 422 Unprocessable Entity error which is mentioned in the docs. And then, trying to use the official action to finish the parallel build, it fails due to an error like No build matching CI build number 111541185 found.

[agronholm]

I'm getting the same error even with the exact same version I used to use before, so I'm guessing something has changed upstream. Now I have absolutely no clue how to get this to work.

[casperdcl]

looks like https://github.com/AndreMiras/coveralls-python-action is a viable replacement for coverallsapp/github-action (and AndreMiras/coveralls-python-action#5 will even allow parallel builds).

[willronchetti]

Did something change recently? This workflow was working with coveralls as of 12/14/2020 (build), yet now it does not?

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-4337388734212009414
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

[scottgigante]

This works for me:

    - name: Coveralls
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        COVERALLS_SERVICE_NAME: github
      run: |
        coveralls

[afinetooth]

Hi @scottgigante.

Just FYI for anyone else reading:

You are correct about those environment variables. Due to the nature of GitHub App authentication, the Coveralls GitHub Action is the only Coveralls integration that must use the repo's GitHub token, rather than its Coveralls-assigned repo token, to identify the repo to the Coveralls API. The way to "trick" GitHub Actions into doing the same for other integrations is to pass COVERALLS_SERVICE_NAME=github, which is the reserved value for the Coveralls GitHub Action.

In other words, the Coveralls API thinks you're using the Coveralls GitHub Action and uses the GitHub token to ID your repo.

Note that v2.X will soon support python and other coverage formats due to using a different underlying integration, the Coveralls Universal Coverage Reporter.