Thanks @xdelaruelle that was really helpful. I’m going to work on some logging on our side to identify the issue.
No problem, thank you for answers and work, take care of yourself! I’ll wait for your actions (debug), write if you’ll need for something (like test run).
The similar for me: Cirrus CI
To the which one uploader? I see “Could not determine repo and owner”: Cirrus CI
@AlexWayfer the changes were made to the bash uploader. I released a new version of the Ruby uploader which should cover your case. Let me know if that works.
Now it seems working! Drop Codecov token by AlexWayfer · Pull Request #24 · AlexWayfer/alt_memery · GitHub
Hi @tom I was wondering if these changes just work for the Bash/Ruby uploaders or also for other (specifically I am looking into the Python one).
If it is possible I can also contribute with a PR for the Python uploader if you point me in the right direction (e.g. which changes need to be made).
Just a bit more about the context of this question:
I am supposing the codecov token is something that is meant to be private and kept secret otherwise malicious users could try to impersonate the project and submit wrong coverage data (I know this scenario is a bit unrealistic/conspiracist, but I am just trying to imagine here the treat model and a possible attack surface area). Moreover, if the token is public, everyone in the internet could be able to read it and use it to submit data unrelated to the project, and thus the very own requirement of the token seem unjustifiable to me.
The majority of CI systems do support some sort of secret management, however these secrets usually cannot be read by regular contributors (non-maintainers, people that do not have write access to the repositories and have to submit contributions via PR). This is exactly the case for CirrusCI.
This means that during a PR, the codecov uploader cannot access the token if stored as a secret (if not stored as a secret, a person submitting the PR could make a change (in the project code itself of the CI configuration, commonly stored as YAML file in the root of the project) in a way to expose the token as plain text in the CI logs.
Not having a coverage report before deciding the merge a PR is very frustrating since code coverage is one factor that might affect the decision.
One could require a review of the code before allowing the CI to run, however I also find this solution not very viable. Running the CI as soon as possible for PRs allow the contributors to quickly fix problems they have introduced without noticing even before the maintainers have time to review the PR, which help saving time and energy. Additionally there are several services that can run in the CI that help to alleviate the load of a review and help the maintainers to take decisions, such as linters, automated security tests, complexity analysers, automatic code smell detectors, etc…
Therefore the usage of tokens seems in my opinion a security dilemma…
Hopefully, since I am using CirrusCI, this dilemma could be avoided.
Just for curiosity, do you have any recommendation regarding this dilemma, or is the codecov token meant to be kept as plain text and publicly visible?
Hi @abravalheri, as far as I know, the only changes will be to add the proper environment variables in this section of the python uploader. It should match the values that are sent to Codecov via the bash uploader.
I would be happy to take a look at a PR if you are able to write one.
I can see that the bash uploader have some tests, however I was not able to see how to integrate something similar to the Python uploader test suite… it looks more complicated.
Thanks @abravalheri, I’ve merged the PR and will be deploying a new version this week.