Coveralls not reporting back to GH PRs

[jrfnl]

Been seeing this for a few days now. PR runs its GitHub Actions checks, sends coverage reports to Coveralls, but never gets the Coverage status reported back to the PR.

The builds do show up on the overview page of the project on the Coveralls website.

Some examples:

• Make codebase compatible with PHPCS 4.0 PHPCompatibility/PHPCompatibility#1911 (already merged, but status still not reported back)
• Syntax/ForbiddenCallTimePassByReference: recognize in additional syntaxes PHPCompatibility/PHPCompatibility#1912 (waiting > 4 hours)
• GH Actions: add Yamllint to basics workflow PHPCompatibility/PHPCompatibility#1909 (waiting > 5 hours)
• GH Actions: Bump actions/setup-node from 4 to 5 Yoast/PHPUnit-Polyfills#266

Coveralls pages:

• https://coveralls.io/github/PHPCompatibility/PHPCompatibility
• https://coveralls.io/github/Yoast/PHPUnit-Polyfills

[jrfnl]

New day, same problem.

[datasage]

I may have the same problem. The reports show up in coveralls.io, but are not finding a base build. This started happening around Aug 30th.

I cannot find any changes on my side that would cause this.

[jrfnl]

Nor me ;-)

Having said that, I can see builds reporting back again over the last few hours.

The problem with them not reporting back, is, of course, that if you have a protected branch and Coveralls set as one of the required status checks, merges are blocked, which get annoying fast if Coveralls does not report back.

[datasage]

I did send an email as well, it seems data is coming through again as of an hour or two ago.

[jrfnl]

This issue is still happening, but intermittently/randomly.
I can have three consecutive PRs running a build and two will get Coveralls reporting back, one will be stuck on "pending completion" for what seems like forever. And even when it eventually completes, it still doesn't report back.

[jsf9k]

Three more examples:

• ⚠️ CONFLICT! Lineage pull request for: skeleton cisagov/skeleton-python-library#154
• Remove the Snyk badge from the README cisagov/skeleton-python-library#155
• Separate Coveralls build results by platform cisagov/skeleton-python-library#156

I'm seeing this issue very consistently.

[afinetooth]

@jrfnl @jsf9k @datasage This sort of issue is usually permissions-related. Specifically, if you're on our legacy GitHub integration, it usually means the token of your repo owner (user) has expired.

The quick fix is to change the owner to a more active member (token sessions = 30 days). But the best solution is to migrate to our New GitHub Integration, which is built on a GitHub App and does not rely on user tokens. It means you can stop worrying about managing a repo owner, and even remove the Coveralls Commenter Bot from your repos / org for PR Comments.

Here's my check on the OP's examples:

1. Repo 1: https://coveralls.io/github/PHPCompatibility/PHPCompatibility — Yes, current repo owner's token had expired (@wimg). I made @jrfnl the new owner.
2. Repo 2: https://coveralls.io/github/Yoast/PHPUnit-Polyfills — No, @jrfnl was already the owner of this repo and token is 👍. But I see that, while GH status checks were sent for some recent builds, they were not accepted at GitHub. Details below:

Example builds

(1) Last PR Build: https://coveralls.io/builds/75443707

• Status sent:
  • "state": "success",
  • "description": "Coverage remained the same at 96.408%"
  • "updated_at": "2025-09-08 17:11:07 UTC"
• Status not received at GitHub.
• Status re-sent today:
  • "state": "success"
  • "url": "https://api.github.com/repos/Yoast/PHPUnit-Polyfills/statuses/6ab9a1b990e037e47019fbfd6316fbdad51b044e"
  • "updated_at": "2025-09-25 18:23:14 UTC"

(1) Last push Build (4.x): https://coveralls.io/builds/75443707

• Status sent:
  • "state": "success"
  • "description": "Coverage remained the same at 98.331%"
  • "updated_at": "2025-09-08 22:34:33 UTC"
• Status not received at GitHub.
• Status re-sent today:
  • "state": "success"
  • "url": "https://api.github.com/repos/Yoast/PHPUnit-Polyfills/statuses/624d52f9d203ba6b6baf2d8aa1ca6ad63b941108"
  • "updated_at": "2025-09-25 18:29:54 UTC"

RCA

I'm afraid I can't speak with certainty on the the root cause of the two example builds above, but since the repo owner's token was valid, I suspect an underlying request out to GitHub may have failed with a SSL error from a specific server—which was the behavior we discovered for the recent Internal Server Error issues.

I am hopeful that future delivery notifications will succeed now that the underlying infra issue has been resolved.