coverallsapp/github-action@v2 seems broken?

[yx-lamini]

It's reporting a gz file does not exist?

The coverall step in CI looks as follows:

[mfrr1118]

Same here. Started happening in the last hour or so for us

[Zeitsperre]

Also am seeing this now in my projects.

[oldbonsai]

I’ll add another voice to the thread. I’ve been having that failure in our CI for about the same time — the last hour or so.

[patattack69]

I also have the same issue with our builds

[cspeper]

➕

[afinetooth]

@yx-lamini Thanks for reporting. We believe this is the underlying issue is coverage-reporter: coverallsapp/coverage-reporter#165

Working on it now. Will update everyone here.

[afinetooth]

Suggestion in meantime:

set fail-on-error input option to false for now:

fail-on-error: false

[afinetooth]

@yx-lamini @mfrr1118 @Zeitsperre @oldbonsai @patattack69 @cspeper We believe we've patched this by updating our checksums file.

Can you please try again to see if it works for you now?

[zmariscal]

I have fail-on-error: false set and it still fails unfortunately. I also see the original issue has a screenshot with this set as well.

[afinetooth]

@zmariscal Thanks. Another user reported the same. We'll have to address that next.

In the meantime, we think we've got it patched. Can you try again and let us know please?

[Zeitsperre]

Confirmed working on my end. Thanks so much!

[afinetooth]

Thank you @Zeitsperre!

We're now fixing the root cause for all subsequent releases.

[oldbonsai]

Also confirmed as working. Thanks for the quick turnaround on this!

[brantphoto]

rca? thanks!

[afinetooth]

@brantphoto RCA:

We added support for linux on aarch64 to this and all future releases of coverage-reporter (as of v0.6.15).

The cross-compilation process was so gnarly that we ended up with completely different directory structures in terms of where intermediate files and artifacts are stored, uploaded and downloaded.

An oversight in this regard resulted in our checksums (coveralls-checksums.txt) pointing to binaries with incorrect paths.

Like this:

59b159a93ae44a649fe7ef8f10d906c146057c4f81acb4f448d441b9ff4dadb3  release/coveralls-linux

When it should have been this:

59b159a93ae44a649fe7ef8f10d906c146057c4f81acb4f448d441b9ff4dadb3  coveralls-linux

That's why we were able to patch the release by fixing our checksums file.

While the fix to the root cause will be replacing this line with this one:

(cd release && sha256sum * > coveralls-checksums.txt)

[mfrr1118]

All good on our end. Thanks

[patattack69]

working for me as well

[zmariscal]

@zmariscal Thanks. Another user reported the same. We'll have to address that next.

Thanks for the fast turn around for the original issue. Would you like for me to create an issue about the fail on failure not working properly?

[afinetooth]

Hi @zmariscal. Thanks for the offer re: the fail-on-error setting. You are welcome to do that but, FYI, right now I am tracking that through an existing issue from our orb integration. (There's even a potential fix there that looks reasonable.)

We intend to apply the fix to both integrations at the same time.

I'm going to close this for now, per the original issue.

As I say, feel free to create a new github-action issue, or you could just follow the related orb issue.

[afinetooth]

@zmariscal wanted to let you know that we just released v2.3.1 of the github-action, which extends the behavior of the fail-on-error input to any failures from "setup" tasks, including:

1. Failure to download the binary;
2. Failure to verify the binary; and
3. Failure to find the downloaded binary after extraction.

This last issue with the github-action related to a checksum verification error (2) during download and verification of coverage-reporter (v0.6.15) (which has since been fixed with a patch), and the reason fail-on-error did not work then was because its behavior only extended to failures of the two commands that can be issued to the binary, coveralls report or coveralls done.

v2.3.1 of the github-action now checks for the success of each setup step and, on failure of any step, returns exit code 1, unless fail-on-error is set to false, in which case it returns exit code 0.

[zmariscal]

@afinetooth thanks for letting me know and your work to fix this 🙇🏼