Zero 0% coverage reported

[ylavoie]

That seems to be a duplicate of #1593 but nothing suggested there had any impact.

Coverage ran fine for years until we decided to run reports in parallel to add Javascript coverage to our Perl application.

Now local branches report ok, while merge pull requests of said branches report 0%.

See https://coveralls.io/builds/52317211 for the local try
and https://coveralls.io/builds/52317710 for the merge attempt.

Moreover, the merge report shows 52% for the Perl part and 0.57% for the UI part, which were expected figures, but 0% for the total.

Any suggestion?

[afinetooth]

Hi, @ylavoie.

We're experiencing an extremely high volume of support requests this week and are working through a backlog. We'll respond to your issue as soon as we possibly can.

In the meantime, I may re-run the jobs in (one or more of) your parallel build(s) to see if you might be affected by a known issue with pull_request builds (vs push builds).

Will follow up here in any case.

Thanks.

[afinetooth]

Hi @ylavoie,

Since your pull_request build showed correct coverage % after I re-ran it, I'm assuming you're experiencing a known issue mentioned in several other recent issues, but described below.

This workaround may fix your issue, and I'd be glad to know if it did:

Workaround for known issue: the Rerun Build Webhook

While we've not yet identified a fix for this issue, we released a workaround today that should resolve it for you: the Rerun Build Webhook.

Since the nature of the issue appears to be that, for some repos with parallel builds:

1. The coverage % of pull_request builds is calculated incorrectly (on the first build), but
2. Re-running the build (recalculating coverage) corrects the coverage %.

A Rerun Build Webhook, similar to the (Close) Parallel Build Webhook, fixes the issue by triggering your build to re-calculate itself.

Instructions

Call this at the end of your CI config, after calling the (Close) Parallel Build Webhook.

Call it like this:

curl --location --request GET 'https://coveralls.io/rerun_build?repo_token=<YOUR REPO TOKEN>&build_num=<YOUR BUILD NUMBER>'

But substitute your repo_token, and your build_num (the same value you used for build_num in your (Close) Parallel Build Webhook).

Please note a few differences between the Rerun Build Webhook and the (Close) Parallel Build Webhook:

1. The /rerun_build endpoint will accept a GET or a POST, and
2. The only two required URL params are your repo_token and the build_num, and build_num is a regular URL param and not part of a JSON body called "payload" as required by the (Close) Parallel Build Webhook:

curl -k https://coveralls.io/webhook?repo_token=<YOUR REPO_TOKEN> -d "payload[build_num]=<YOUR BUILD NUMBER>&payload[status]=done"

[afinetooth]

NOTE: In case you're having trouble determining what build_num is for your project, I posted some follow-up here.

If you're using a different Coveralls integration and/or are still having trouble determining the correct values for either build_num or repo_token let me know here, or in the context of your issue, or at support@coveralls.io.

[ylavoie]

As discussed in #1631, I cannot have success with GITHUB_TOKEN, only the value which is displayed on coveralls repository homepage works.
Now is that an error in the hook code? If not, how does GitHub actions get hold of that securely to feed the hook?

And even with the repo_token, I don't see any changes after sending the rerun.
See https://coveralls.io/builds/52702588 or https://coveralls.io/builds/52702522, for example.

[afinetooth]

@ylavoie sorry for the delay. Are you still having this issue?

I do see that the last two builds you mention continue to be affected:
https://coveralls.io/builds/52702588
https://coveralls.io/builds/52702522

I feel certain that the coverage % will correct itself on those when I re-run them.

I'm sorry if you're not able to trigger a rerun with the Rerun Build Webhook. Can you please share the error message from your CI build log?

To answer your questions:

I cannot have success with GITHUB_TOKEN, only the value which is displayed on coveralls repository homepage works.

That's right. The workaround does require the standard Coveralls Repo Token.

The Coveralls Github Action is an exception to the rule, in terms of Coveralls integrations, in that it's one of the few integrations that use your repo's ${{ secrets.GITHUB_TOKEN }} to identify the repo at the Coveralls API. But a unique Repo Token is assigned to all repos at Coveralls, so we standardized the /rerun_build webhook around that.

Now is that an error in the hook code? If not, how does GitHub actions get hold of that securely to feed the hook?

No, not an error. Github does not have a way to obtain the Coveralls Repo Token. You have to add it yourself to your workflow config file. There are several ways to do that, but the safest is to add it as a Secret, then use the secret in your call to the Rerun Build Webhook:

1) Add secret

Add secret here: https://github.com/afinetooth/coveralls-demo-ruby/settings/secrets/actions

2) Use secret in Rerun Build Webhook

      - name: Rerun Coveralls Build (Workaround)
         run: curl --location --request GET 'https://coveralls.io/rerun_build?repo_token=${{ secrets.COVERALLS_REPO_TOKEN }}&build_num=${{ env.GITHUB_RUN_ID }}'