Skip codecov uploads on forks

[jacobtylerwalls]

Type of Changes

	Type
✓	🐛 Bug fix

Description

Prevents failures on forks like

[2023-06-22T21:57:58.791Z] ['verbose'] The error stack is: Error: Error uploading to [https://codecov.io:](https://codecov.io/) Error: There was an error fetching the storage URL during POST: 404 - {'detail': ErrorDetail(string='Could not find a repository, try using repo upload token', code='not_found')}

I don't think it should be required to set up a repo with CodeCov to fork pylint. WDYT?

[codecov]

Codecov Report

Merging #8794 (e1190a8) into main (e33920f) will not change coverage.
The diff coverage is n/a.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #8794   +/-   ##
=======================================
  Coverage   95.83%   95.83%           
=======================================
  Files         173      173           
  Lines       18526    18526           
=======================================
  Hits        17755    17755           
  Misses        771      771           

[Pierre-Sassoulas]

On the other hand it's nice to be able to ?

[DanielNoord]

Is there an easy way to re-enable this on forks that do want to upload?

[jacobtylerwalls]

Is there an easy way to re-enable this on forks that do want to upload?

Removing this line, I suppose.

So it's just about who should have to take the burden of being uneven with upstream on their forks: people who want to configure codecov, or people who don't.

If we don't go this route, we should add some links to the contributor docs about how to get started. I don't know how much time I'd be sinking into this to get codecov running on my own fork, for instance.

[Pierre-Sassoulas]

This would create hard to debug issues if the main repo name change and it's making a fail implicit on forks. Even if a contributor don't want to set up codecov on a fork the error would remind them that coverage needs to be checked locally. Also the main use case if you're lazy is to open a MR (directly or not) on main so I think most would do that and it's more likely we're going to bother perfectionnists that only want to open perfectly mergeable MR on the first try.

[jacobtylerwalls]

Makes sense. I'll close :-)