"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)

[AlekSi]

Using a token works – if you are willing to make it public.

[amotl]

Dear Tom,

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

We have been following your advice on a few repositories, thank you very much. However, the problem is that this will not work on PRs being submitted from repository forks, i.e. by external contributors.

To be more precise, it will not work when storing the upload token within GitHub's repository secrets slot, see also https://github.com/caronc/apprise/issues/715#issuecomment-1297932756:

Note: With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository.

-- https://docs.github.com/en/actions/security-guides/encrypted-secrets#using-encrypted-secrets-in-a-workflow

So, we are very much looking forward to see this issue being resolved on behalf of the upstream infrastructure at GitHub and Codecov.

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

May we humbly ask about any news on this topic?

With kind regards, Andreas.

[thomasrockhu-codecov]

Hi @amotl,

I know that this is going to run into issues with forks, and I just don't have a good solution. The best I can offer is that you could try re-trying the Action step a few times. This is really not ideal, and we're working on a few fixes on our side to help here.

Be assured, this is biggest issue on my plate, and I'll be tracking our progress here.

[amotl]

Dear Tom,

I appreciate your response very much. Good luck to you and the team for resolving this hairy issue.

With kind regards, Andreas.

[ChristoWolf]

Just wanted to chime in that I'm also experiencing this issue on a public repo. Sometimes the action works, sometimes it fails exactly as described.

[pacoorozco]

Hi! As several of you I'm getting the error Unable to locate build via Github Actions API. Please upload with the Codecov repository upload token to resolve issue. using the latest version of the GHA in a public repository.

You can see it here

[adrinjalali]

Not a solution, but maybe helpful for folks: https://community.codecov.com/t/upload-issues-unable-to-locate-build-via-github-actions-api/3954/1

[anthrotype]

We're hit by this in all our projects (all are public github repos, with codecov token stored in the repo secrets and sourced from the CI yml, which receive PRs from other forks from which secrets are not accessible, hence upload fails randomly each time codecov fails to locate build via Github API).

I'm trying to understand what's the worst that can happen if I simply paste the full codecov token in plain un-encrypted text inside the CI config?

[adrinjalali]

Same here, adding the token to the config/repo hasn't resolved the issue.

[ChristoWolf]

Hi! Are there any news regarding this issue?

[thomasrockhu-codecov]

@anthrotype the worst thing that could happen is that a malicious user could upload trash coverage reports to your repo, which would result in incorrect coverage changes. The token is siloed specifically to help Codecov identify and verify that an upload is coming for a specific repository, but it is not used for anything else.

Since we are unable to get around GitHub's rate-limiting policy, it is strongly advised to add the token in your repos to get consistent coverage results. We are still exploring other possibilities, but a solution may be to remove tokenless uploading for OS projects.

For anyone else experiencing this issue, please try the following troubleshooting steps.

1. Use the Codecov token (as a secret or hard-coded value only if you need outside collaborators to have access)
2. Ensure that the token is found by the uploader. Check the logs and ensure that they don't say

   [timestamp] ['info'] -> No token specified or token is empty

3. Add the Codecov GitHub app
4. Open a topic on the Codecov community boards

I'm going to close this issue as we will be tracking it here.

[aaron-ai]

Same here.... https://github.com/apache/rocketmq-clients/actions/runs/4562124132/jobs/8048921873

Even worse, it seems that we are unable to obtain the project's Codecov token as the project belongs to the Apache Software Foundation...

[danepowell]

For anyone else like me thinking you could be clever and use the new GitHub configuration variables to pass the CODECOV_TOKEN to your workflows: variables have the same restrictions as secrets and won't work for pull requests, even though this isn't well-documented.

The only option is to hardcode the token in your workflow. This is okay-ish since the token has limited scope, but it still makes me cringe. 🤮

[adamjstewart]

Any updates on this? This bug has been present for over 2 years and affects dozens of repos.

[MetRonnie]

A workaround is to upload the coverage in a separate job, like we did here: https://github.com/cylc/cylc-flow/pull/5459

• Reduces how hard we hit Codecov API
• Allows easy re-attempt to upload
• Makes clear the separation between test status and Codecov upload failures

[thomasrockhu-codecov]

@MetRonnie this won't completely solve the issue with hitting GitHub rate limits for now. We recommend just using the CODECOV_TOKEN if possible

[adamjstewart]

CODECOV_TOKEN only works for PRs originating from the upstream repo. Any fork, even if it's from the maintainers of upstream, will still have the same issue.

[thomasrockhu-codecov]

@adamjstewart that is definitely true. It has unfortunately been a hairy problem for us for awhile. We are looking to see how to implement tokenless uploading for forks in a way that will allow us to stay under the rate limits

[air3ijai]

@thomasrockhu-codecov

We are looking to see how to implement tokenless uploading for forks in a way that will allow us to stay under the rate limits

But what is about v4.0.0-beta.1 with breaking changes?

[dopplershift]

@MetRonnie this won't completely solve the issue with hitting GitHub rate limits for now. We recommend just using the CODECOV_TOKEN if possible

I just implemented this and the benefits I saw were:

1. Fewer API calls (less stress on codecov)
2. Reduced opportunity to run into this problem
3. Simpler, single job to re-run rather than needing to re-run the full test suite/matrix

(Thanks to @MetRonnie for sharing!)

[morremeyer]

@air3ijai I have opened codecov/feedback#124 for the tokenless upload being removed in v4 since this is tangential here, but another issue. This should help separate these discussions.

Current workaround: I'm using this configuration which specifies a token.

This works even in forks, where the action logs:

[2023-10-23T19:34:12.960Z] ['info'] -> No token specified or token is empty

and then uses the tokenless upload.

[adamjstewart]

At this point, the above error message is almost a daily occurrence for us, and I spend more time re-running one or multiple of our test suites or explaining to contributors why the drop in coverage isn't there fault than I do actually using the metrics codecov gives us. If we can't trust our coverage metrics, then they are no longer useful to us. We're seriously considering switching to a new coverage platform since it seems like no progress has been made on this issue since it was first reported in 2021. We'll either try @MetRonnie's workaround (you are a lifesaver) or explore other alternatives.

[drazisil-codecov]

This is an issue with Codecov hitting the GitHub API rate limit. There is little we can do about this, since GitHub won't

a. Raise the limits b. Support using multiple apps to get around the limits.

As suggested above, it is best to use your own upload token so that you are not running into Codecov's rate limits with GitHub, and we can instead use yours. Otherwise all users using tokenless (aka, Using Codecov's API token for GitHub) will continue to encounter this issue.

I recommend setting the token as a repo secret via https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#creating-secrets-for-a-repository or your CI providor's settings.

[adamjstewart]

We do set the token as a repo secret, but that only works if the PR is contributed from an upstream branch, which none of ours are.

[MetRonnie]

Yeah, just to reiterate that if a PR comes from a fork then the token isn't used

[drazisil-codecov]

Yah. We haven't found a way around that unless you just hard-code the token. Which you could, and it wouldn't cause harm, but I understand that as a secret that's bad form. We are still looking for solutions, but it's not easy. Tokenless/Public repos use a lot of API calls (that's a good thing, I love to see you using Codecov, I just wish it was a better experience in this regard.)

[rohan-at-sentry]

Hi everyone

We've released a new version of the codecov action and CLI that should support tokenless uploads from forks. Here's a link to our blog outlining the latest update including how to upgrade to the CLI. You can also visit our docs for more detailed information on how to get set up with the CLI, especially if you're not using our Github Action, Bitrise Step or CircleCI orb.

Currently, tokenless uploading is only available to forks attempting to create PRs on public repositories. This means that for most use cases, you will still need a token, even for public repositories. However, contributors creating PRs from their forks to the upstream repo will be able to get coverage information from Codecov.

[adrinjalali]

FWIW, I haven't seen this error since we made sure the token is available, And since there's not much of a consequence in having the token public, we have it included in the repo in clear text in the coverage.yml file. Pretty much anybody can upload coverage for your projects at any time anyway, so doing this basically solves the issue.

[kdarkhan]

I have implemented an approach for passing secrets by having 2 workflows:

1. on.pull_request workflow which does not have access to secrets. It stores the coverage report to Github artifacts.
2. on.workflow_run which triggers after every on.pull_request completion. It has access to secrets, and downloads the artifacts, and uploads reports to Codecov.

This is implemented by https://github.com/google/mdbook-i18n-helpers/pull/162/ and https://github.com/google/mdbook-i18n-helpers/pull/168.

[adamjstewart]

@kdarkhan why did you use custom JavaScript code instead of https://github.com/actions/download-artifact? Does download-artifact not have access to artifacts created by forks?