"Unable to locate build via Github Actions API" for the public repository

[AlekSi]

Seems to be the same as closed codecov/codecov-action#557.
Similar to codecov/codecov-action#803 and codecov/codecov-action#598.
Here was a request to create a new issue in that case, so here it is.

https://github.com/FerretDB/FerretDB/actions/runs/3130125909/jobs/5080024795

[yurishkuro]

Getting the same several times today, but it is transient: https://github.com/jaegertracing/jaeger/actions/runs/3136909140/jobs/5094405179

[thomasrockhu-codecov]

@AlekSi @yurishkuro if you have installed the Codecov GitHub app, the only reason I can think of for getting that message is that the access token used is hitting a GitHub rate limit. Do you use any other GitHub apps or know why that might be?

[yurishkuro]

I don't think we're using the app, we use GH Actions here: https://github.com/jaegertracing/jaeger/blob/e877a61926a3f7bc1a5f5ba6b9fceb78bcb8b71d/.github/workflows/ci-unit-tests.yml#L26

[thomasrockhu-codecov]

@yurishkuro to be clear, those two things are not mutually exclusive. The app is used by Codecov to communicate with GitHub (e.g. check the codecov yaml, post the PR comment and status checks). The Action is used to upload coverage reports to Codecov.

[yurishkuro]

Yes, we do have Codecov app as well. But the errors are coming from GH Action.

[AlekSi]

to be clear, those two things are mutually exclusive

I guess you mean "are not".

Yes, we do have that app installed. We also use a few other GitHub apps. Do they all use the same token (and what token is that)?

[GiyoMoon]

I'm also getting this error in a public repository:
https://github.com/GiyoMoon/astrolabe/actions/runs/3146676402/jobs/5115391452#step:6:30
It worked 5 days ago:
https://github.com/GiyoMoon/astrolabe/actions/runs/3114152120/jobs/5049659188#step:6:53

[AlekSi]

I enabled verbose mode: https://github.com/FerretDB/FerretDB/actions/runs/3151343738/jobs/5125175424

[jgarivera]

I also have the same error during this run. codecov/codecov-action@v2 was able to upload successfully though.

[YonatanKra]

Hi,
Worked fine this morning - started again now.

[GiyoMoon]

Oh great, I just re-run my job and it worked too.

[thomasrockhu-codecov]

I am wondering if the disruption with GitHub had anything to do with this uptick in this issue. If so, apologies, I know the error message could have been far better crafted. We are working on making it more actionable.

As far as I know, this error message happens when we ping GitHub to confirm that the build being uploaded to Codecov matches with a real build for the same repository. This is one of the checks we do for public repositories that aren't using an upload token. I'm guessing that API call went a little haywire a few days ago.

[AlekSi]

That accident was resolved 6 days ago, but we are seeing the same issue right now: https://github.com/FerretDB/FerretDB/actions/runs/3175008916/jobs/5172514896

[thomasrockhu-codecov]

Ok, I think I tracked down the underlying issue here. I've made a ticket for the product team

[thomasrockhu-codecov]

I'll be tracking progress on this communty post

[thomasrockhu-codecov]

In the short term if this is actively blocking you, I would suggest using the upload token 😬

[MetRonnie]

We've got a public repo, the Codecov GH app installed, CODECOV_TOKEN stored in secrets, using with: token: ${{ secrets.CODECOV_TOKEN }} but still getting "Passed token was 0 characters long"

Example (succeeded on this occasion, but failed another time before I enabled verbose mode): https://github.com/cylc/cylc-flow/actions/runs/3196165816/jobs/5217734063#step:16:102

[AlekSi]

Secrets are not available for pull_request events from forks: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories

[dixudx]

Github action codecov/codecov-action@v2 used to work, but failed these days.

So I try new version codecov/codecov-action@v3. It just goes back to normal. 😄

[MetRonnie]

So the problem seems to be that, without the token, the upload is getting rate limited sometimes, and thus failing. And using the token in the action does not work for PRs from forks as @AlekSi has pointed out.

(This is the case for v3 of the action)

[melink14]

@adamjstewart I might be missing something but I don't see where you uploaded the commit ref for later downloading in your coverage action. The action seems to be getting it from the github event object still.

[kdarkhan]

@adamjstewart I see you are using github.event.workflow_run.pull_requests.head.sha here - which does not work as I described in google/mdbook-i18n-helpers#168.

The syntax should have been github.event.workflow_run.pull_requests[0].head.sha - but due to a bug in Github actions event passing, it is flaky.

My workaround is to get this sha from the original PR as I described higher.

[adamjstewart]

Thanks for the link. I'm slowly rediscovering all the reasons you had to jump through so many hoops. I think I've managed to find a simpler way to download artifacts than what you're using, but it looks like all the rest of your JavaScript is still necessary.

Need to decide if we're expected to implement all of this ourselves or start looking for codecov alternatives. Would love an official response from codecov as to how they expect people to use their action.

[yurishkuro]

Even with v3, it works 50% of the time at best due to GitHub's API rate limits.

@adamjstewart could you elaborate how GitHub API rate limits are in play here? Why does having a Codecov token make a difference w.r.t. GH rate limits?

[rohan-at-sentry]

@adamjstewart - I'm a PM on the codecov team.

I'll take a look at why you're having the issue you described here, what you're describing is not the intended set up experience here. I'll respond back here with an update as soon as I have one

[rohan-at-sentry]

@yurishkuro

To clarify, the reason why a token-less only approach has been so problematic over the past few years has been due to GitHub's rate limiting. Tokenless generally works by making an API call to GitHub to confirm that the repo and commit are the correct values. Making this call for thousands of repositories causes our GitHub token to hit the limit causing the issues that many of you have seen (e.g. Unable to locate build via Github Actions API).

As a result, we needed to make decisions on how best to serve our users. This means that tokenless uploading is not currently sustainable until GitHub allows for higher rate limited APIs.

The open source (OS) community is a major user and proponent of Codecov. A very common flow for them is to have outside contributors fork the repo, make changes, and open a PR to the upstream repository with that change. Unfortunately, GitHub does not have a way to share secrets with contributors. In order to provide support for these OS projects, we added a way for open source contributions to forks not require a token

[thomasrockhu-codecov]

Hi all (@kdarkhan @adamjstewart @melink14), I'm moving the conversation over to this issue regarding workflow_run. I think this particular issue is unrelated.

[melink14]

To clarify for future readers, the reason it is related to this issue is that it explains how to securely use codecov for PRs from forks in public OS repos.

There's no problem except that GitHub has some bugs and makes the process annoying for security reasons (as far as I know).

I guess the other issue can be used to investigate simplifications to the process.

[ST-DDT]

I recently noticed an increased error rate regarding tokenless for PRs (we are using codecov action v4.1.0).

Is there a solution recommended by the codecov team on how to solve that?
Could you extend your Setup GithubAction guide to include that recommendation?

[thomasrockhu-codecov]

@ST-DDT can you open a new issue about that? I'm going to close this one as the solution to the original is to add the token.

[ST-DDT]

can you open a new issue about that?

Done: #301

• Document how to properly setup Codecov Github Action for OpenSource repositories #301