-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document how to properly setup Codecov Github Action for OpenSource repositories #301
Comments
It might be hard to find the workaround I came up with from the linked issue, adding it here if that becomes useful. I ended up using 2 workflow approach which seems to work pretty stable with token based auth for forked repos. This workflow uploads coverage report to Github artifacts and this workflow uses that report and the token to upload it to codecov. |
@ST-DDT thanks for raising. For context (which you probably already realized from the screenshot - but may benefit others), v4 allows tokenless uploads for forks ; enabling open-source contributors to upload coverage. Because this happens without a token, Codecov uploads from forks upload using Codecov's own token - you can see how quickly that can get consumed leading to a failure. That is most likely what is happening when you see
In effect - uploading from a fork should be (from a reliability standpoint) no different from before v4 was released. Is it possible for you to confirm if the rate is worse since Feb of this year? Also - I'm curious if the workaround here worked for you |
I think the rate remained the same.
No, we are currently in a feature freeze and thus have very few external contributions. |
I tried to use the above workaround. Didn't try the full thing with hundreds of lines of JavaScript code, but it was too complicated to get working with the usual upload/download artifact actions. TorchGeo gets 99% external contributions, so we're very keen on getting this working. |
Hey folks cc @ST-DDT @adamjstewart We're exploring the best path forward for a fix here. Here's the current thinking - codecov/engineering-team#1574 We'd expect this to be ~ 4 weeks of work.. I'll report back here once this is complete. We're shooting for something that doesn't require more config. thank you for your patience. |
Meanwhile, we've better documented the tokenless flow in our docs . In general, there shouldn't be a need to implement workarounds to pass the token to forks that can then use it to upload to Codecov. |
It would be nice to expand
with an information about the actual first version that supports that behaviour. |
Could also replace:
with:
as the former is much more common (at the moment) 😏 But seriously though, thanks for all of your hard work to improve the situation. I know how difficult it is when GitHub refuses to increase the rate limit for a token and security is involved. I'm sure you're drowning in bug reports at the moment. Looking forward to a working solution, and happy to help test on our repo! |
Agreed, updated |
Thanks for your patience as we work through this. <3 |
Hi folks, |
That is the workaround discussed in #126. See #126 (comment) for why that's currently way too difficult to get working properly. Of course, if there was a documented solution or simplification of this that worked, that would be fine. But a solution that allowed PR coverage to be uploaded without a secret and upstream repo coverage to be only uploaded with a secret would also be fine with me. |
@adamjstewart I was thinking something slightly different - but maybe this is naive as I don't really know how codecov works under the hood :
|
A comment would be better than nothing, but the ability to view the diff and missing coverage on the codecov website would be better. I don't think it would be a security issue to upload PR coverage without a secret, as long as a secret is still required for protected branches like main. |
Based on previous comments it seems Codecov is working on a solution to this. I don't know how they are planning to resolve this but I believe something like the workaround I used in #301 (comment) can be packaged as reusable actions. The workaround works pretty well but is verbose to implement. They could define 2 GitHub actions:
If done properly then users could just use 2 actions without extra verbosity of JS scripting. |
Describe the bug
PRs from external contributors fail CI.
Environment (please complete the following information):
To Reproduce
Steps to reproduce the behavior:
External contributors have a near 100% chance at failing. Internal contributors have a near 0% chance at failing.
Expected behavior
The CI is expected to work.
Or alternatively the guide describing how to setup the action should provide hints on how to deal with the error.
Screenshots
Additional context
Created on request here:
Affected CI pipelines:
The text was updated successfully, but these errors were encountered: