Coverage threshold for failure as input to gha

[pbhandari-turo]

According to the docs, the only way to set the "COVERAGE THRESHOLD FOR FAILURE" and "COVERAGE DECREASE THRESHOLD FOR FAILURE" is via the UI or using the PUT/POST api.

Using this action should not require any configurations outside and the POST /api/repos request params like comment_on_pull_requests, send_build_status, commit_status_fail_threshold, commit_status_fail_change_threshold should we made available as inputs to this action.

Am I missing something or is this not supported right now, if not are there any plans to do so? Thank you!

[afinetooth]

Hi @pbhandari-turo. Thanks for the input. We are considering adding some of the functionality of the Coveralls API's /repos endpoint to our official integrations as a result of it.

tl;dr:

Interacting with the /repos endpoint of the Coveralls API is not a supported feature of any Coveralls Integrations that I'm aware of at this time. The scope of most Coveralls Integrations is solely about interacting with the /jobs endpoint.

That said, there's nothing preventing users from also interacting with the /repos endpoint of the Coveralls API from CI build scripts or other automation tools.

Details:

Let me explain what's supported by Coveralls Integrations now, and why, along with a typical use case that entails both the /repos endpoint and the /jobs endpoint:

The Coveralls "integration" model (/jobs endpoint)

Since our inception around 2011 our notion of a Coveralls Integration has been a gem, package, script or executable that you add to your project (repo) that runs in CI when you run your tests and test coverage, then sends coverage reports to Coveralls.io (by posting them to the /jobs endpoint of our API), where a job = one run of tests (and test coverage) in CI.

Back then we provided the API portion of our service, for free, along with a couple of integrations in Ruby and Javascript that offered the open-source community a model for achieving this limited scope, for projects in other languages. Fast forward to today and there exists >30 Coveralls Language Integrations following that model.

Support for full automation (/repos endpoint)

Also since inception, we've offered a Web UI for adding your repos to Coveralls.io, whereby we leverage an integration to your git service (first Github, then later Gitlab and Bitbucket) to create a parallel "Coveralls Repo" for your git repo.

Later, we heard from users that they wanted to automate this entire process, so we added access to the /repos endpoint so that users could programmatically add their repos to Coveralls.io and, simultaneously, set the Repo Settings (previously only available through the UI) that control the behavior of Coveralls once it starts receiving coverage reports for the given repo.

Typical use case for interacting with both /repo and /jobs endpoints

Providing POST/PUT access to the /repos endpoint gave users a place to expand the automation possibilities of their git repo lifecycles. As explained in our docs here, the typical use case is:

Typical use case: A user writes a script that: (1) programmatically creates a new Coveralls repository, providing any non-default configuration settings; then (2) receives back a JSON representation of the repository along with its repo_token; then (3) uses that token to send coverage reports to Coveralls at the /jobs endpoint.

The future

For the past several years we've been trying to simplify the integration process for all coveralls users, across all language communities, by standardizing it, so we've been focusing on our "official integrations," and, since 2022, we have been making strides with our Universal Coverage Reporter, which is a cross platform executable that supports a widening set of coverage report formats and CI services, and now underlies new versions of all official integrations.

As we add further support for more coverage report formats and CI services to the Universal Coverage Reporter, we expect that more and more users will migrate to the Reporter or to the official integrations/CI extensions fronting it, so that we can expand the functionality of our official integrations to meet the greatest number of use cases for the widest audience of coveralls users.

Thanks for providing some of the first helpful suggestions about how we can improve those official integrations.