Upload Issues (`Unable to locate build via Github Actions API`)

Hi everyone,

We have recently seen an influx in issues regarding uploading with the error message Unable to locate build via Github Actions API. The reason for the failed uploads is due to Codecov’s inability to check the validity of a coverage upload when using tokenless uploads. The underlying issue is rate-limiting from GitHub.

Am I having this problem?
If you are not using GitHub Actions, this problem should not affect you. The best way to find out is to see if you have had any failed GitHub Actions checks with the following error message Unable to locate build via Github Actions API in the Codecov upload step.

What should I do about it?
Although there is no 100% way of guaranteeing success, we recommend two ways of dramatically increasing successful uploads:

  1. Add in the Codecov upload token even if your project is public. It is recommended to add it as an environment secret as opposed to hard-coding.
  2. Re-trying the upload step in CI/CD.

What is Codecov doing about it?
Right now, we are exploring various options to decrease our use of GitHub’s API. We anticipate a longer-term solution in the next few weeks.


EDIT 2023-03-13:
The issue is still ongoing, and we are taking steps to decrease our GitHub API use. At this point, we strongly recommend using the Codecov upload token to upload to Codecov.

Public repositories that rely on PRs via forks will find that they cannot effectively use Codecov if the token is stored as a GitHub secret. The scope of the Codecov token is only to confirm that the coverage uploaded comes from a specific repository, not to pull down source code or make any code changes.

For this reason, we recommend that teams with public repositories that rely on PRs via forks consider the security ramifications of making the Codecov token available as opposed to being in a secret.

A malicious actor would be able to upload incorrect or misleading coverage reports to a specific repository if they have access to your upload token, but would not be able to pull down source code or make any code changes.

2 Likes

(this is the repository most affected for me, but I use codecov on several repositories)

1 Like

Hit this again when I had to retry twice to get this setp to pass. A side effect of retrying manually though is that the check which waits for Codecov’s analysis never seems to pass and I had to override and merge without waiting for codecov’s results.

Repo: https://github.com/melink14/rikaikun
user: melink14

Thank you for offering to keep us posted. We’ve been affected too. We’ll be happy to get the follow ups on repo https://github.com/ReadAlongs/Studio . My GitHub user name is joanise.

I’ve added my codecov token to GH Actions, and so far that worked well, so thanks for that.

Your second suggestion is to retry the upload step, but we use codecov/codecov-action@v3 and I don’t see a retry parameter in there. Is there a straightforward way to retry while keeping that action plugin?

1 Like

One more question: Am I correct in assuming that when I use my CODECOV_TOKEN, the upload is actually more efficient because it’s pre-authentified and no further validation is required?

@jonny7 that is roughly correct

Any update? This affects our repos as well:

We use a codecov token, and we were able to upload earlier today, but the failure is consistently happening now, after multiple retries.

We see this more or less on a daily basis on this repo: GitHub - skops-dev/skops: skops is a Python library helping you share your scikit-learn based models and put them in production

GH username: adrinjalali (adrinjalali (Adrin Jalali) · GitHub)

We have added the token to the GH action, but the issue still persists. It doesn’t seem like a rate limit issue though.

@adrinjalali, I don’t believe you are passing in a token, see this log

but we are passing the token here: skops/build-test.yml at 78c5ef4ff27f928b92c981a76a1278033212a170 · skops-dev/skops · GitHub

And we’re getting errors again all over: Fix for metadata having model format · skops-dev/skops@08cbffd · GitHub

@adrinjalali I believe there might be an issue with how you have set the token in GitHub. I’m seeing this log that no token is being passed in.

Github username - dilanSachi
Repository - ballerina-platform/module-ballerina-ftp

@tom in November you said you hoped to have a long-term solution in a few weeks, do you have any update on this? It seems to still affect dozens of users, including our repo: GitHub - typhonius/acquia-php-sdk-v2: A PHP SDK for Acquia Cloud API v2 https://cloud.acquia.com/api-docs/#

Also just cross-referencing this GH sister issue: "Unable to locate build via Github Actions API" for the public repository · Issue #837 · codecov/codecov-action · GitHub

@danepowell I don’t have any updates, we are still working with the GitHub team to try to make tokenless work for our users.

If this is not working for you, please add the Codecov token to your CI environment variables

@tom I think saying “Adding in the Codecov upload token even if your project is public.” is a bit misleading and I have seen a fair amount of people mentioning hard coding that secret. Would it be possible to rephrase to encourage good practice and using an environment variable (whatever the CI tool might be)?

1 Like

Updated @arthurio, let me know if that makes sense.

1 Like

That’s the only possible way for GitHub Actions, public repos and PRs from forks – they don’t have access to secrets: Events that trigger workflows - GitHub Docs

I know, but Github Actions is not the only one CI provider :wink: That’s why I used the word “encourage”. Also, for Github, my understanding is that pull requests from forks to the main repo will trigger the actions from the main repo, which means they do have access to that secret. I’m not sure I see a benefit to letting forks upload coverage against your main repo if it’s not a PR for merging upstream, or am I missing something?

I know, but Github Actions is not the only one CI provider :wink:

This topic is about Github Actions, though

Also, for Github, my understanding is that pull requests from forks to the main repo will trigger the actions from the main repo, which means they do have access to that secret.

From the link I provided above: " With the exception of GITHUB_TOKEN , secrets are not passed to the runner when a workflow is triggered from a forked repository." That’s from the section pull_request.