"Unable to locate build via Github Actions API" after switching to v2 action, v1 works fine #557
Comments
|
I'm also running into this uploader issue, which is currently being addressed by the codecov team. Here are the related links: |
|
Ah thanks for the links 👍 I checked for other issues on this repo to see if anyone else had already reported this but I did not know to check on https://github.com/codecov/uploader |
|
I'm also seeing this error with |
|
Update 4: Back. It smells like a rate limiter issue |
|
This issue looks like it is resolved after codecov/uploader#426 was merged and https://github.com/codecov/uploader/releases/tag/v0.1.6 was released. |
|
Can confirm this is now resolved - thanks 👍 |
|
I am not sure to which extent this was fixed because lately I seen more and more random errors like this. https://github.com/ansible-community/ansible-lint/runs/5625894991?check_suite_focus=true |
|
Same here. Should this issue be reopened as long as this is still affecting users? |
|
TBH, this proved to be a major cause of build failures and the solution would be to make the action itself have an implicit retry logic with delay, maybe even with 5min. 99% of failures are transient and retries would succeed, so I hope they will do the right think and implement that, especially as it is impossible for the consumers to do the same, due to the limitation of workflows. |
|
In my case I was getting the same error, and I managed to fix it thanks to #295. The error was when running
The solution was to run |
|
During the last 2-3 days I observed a huge spike in number of failed uploads due to 404 error and I checked neither Github nor Codecov reported any outages while this was happening. This is really failing our jobs and if the upload has real changes of failure, we should have an implicit retry mechanism embedded in the upload logic, so we avoid breaking these. |
|
The issue here is for tokenless uploads to work, we need to use our API token instead of yours. Given how many public repos we support, we hit our rate limit with GitHub fairly often. We have been in discussions on how to handle this, but a retry would not have helped and only made things worse in this case, as I believe that GitHub will extend the delay if you keep making the same request after they tell you no. Sorry, that's not an ideal answer. |
|
In fact is is a good answer. The problem was that the error message does not mention this limitation and the docs are clear: "if is public you do not need a custom token". Fix these two places and we will know what to do. Just mention that rate limiting for public can produce this error and users will know what to do. I will start adding the tokens, is not really a bit issue, is just that that is the first time when I know why to docs is misleading. THANKS! |
|
Using token from your "Let's get your repo covered" site seems to solve this issue (even is it is bolded there that no token is needed for public repos). |
|
@TomaszZieleskiewicz @drazisil-codecov Apparently we still face random 404 error even after adding The fact that thing problem was not addressed in years drives will drive people out of codecov. Is not that it was not known, it is just that it was never considered important enough. Why we do not have at least two retries with a delay of 1 or more minutes in between? It would be acceptable if the failure rate would like 0.1%, but if the failure rate is 2%, that translates to 22% for a pipeline that has 10 uploads, because 1.02^10 ~ 1.22, and that is only due to failure to upload coverage. I think that the only thing that I can do now is to reconfigure the pipelines to ignore failures of this step. It is dangerous but likely less damaging than getting broken builds due to coverage. I would not have posted this long comment if it was just yet another random upload failure, it is more than that. By reading comments from #598, I am wondering if the repository secret might not be available to pull requests coming from forks. Is that true is not really clear which is the right way to reconfigure the jobs. No wonder that we might get frustrated about a case where docs mention token is not needed for public repos, but in fact it is needed for practical use, but it might not work for some pull requests even when given,... |
|
@ssbarnea, what have helped me, and what I thought you suggested was adding token not only to secrets, but to CI yaml as well. Like that: Have you tried it? |
|
I seen something very weird in my verbose logs from the pull request, "no token was used or the token was empty", the change that was adding the line you mentioned. I now updated the token from repository secrets but I doubt it was really empty. Somehow I suspect that github does not pass the repository secrets for pull requests from forks, as a security measure. Still that token is a weak secret and it is absolutely needed to see the coverage for incoming pull request, probably more important than even measuring it on main branch. |
Although open source projects don't require upload with token, CodeCov default token meets limits sometimes, resulting in failed uploads. See more details here: codecov/codecov-action#557 (comment). The solution is to use our own Codecov token.
Add CODECOV_TOKEN to fix codecov/codecov-action#557
Add CODECOV_TOKEN to fix codecov/codecov-action#557
Although open source projects don't require upload with token, CodeCov default token meets limits sometimes, resulting in failed uploads. See more details here: codecov/codecov-action#557 (comment). The solution is to use our own Codecov token.
Reference: codecov/codecov-action#557 Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
to work around rate-limiting issues like codecov/codecov-action#557
Reference: codecov/codecov-action#557 Also, set `fail_ci_if_error` to `false` to prevent the CI from failing in case the Codecov servers are unstable or down. Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
* Don't fail CI if unable to upload to codecov * Use our own codecov token to avoid rate-limiting See codecov/codecov-action#557 (comment)
After receiving an email about the pending deprecation of the bash uploader, I decided to start migrating my repos to use the v2 uploader.
I tried switching one of my repos to the v2 (binary) uploader: chris48s/django-apiblueprint-view@c029bae
Unfortunately the upload is failing with the error:
Full output:
As I understand the docs, public repos should still be able to upload coverage from GH actions without a token.
I switched the repo back to use the v1 (bash) uploader: chris48s/django-apiblueprint-view@77518ba and that fixes it.
Full output:
The text was updated successfully, but these errors were encountered: