add get_repo_provider_service fn to base task

[matt-codecov]

get_repo_provider_service() can raise two exceptions which we do not consistently catch. from a quick scan of usages, it appears to make sense to handle them the same way across tasks, so this PR adds a wrapper method to BaseCodecovTask that behaves as follows:

• calls get_repo_provider_service()
• if RepositoryWithoutValidBotError, call save_commit_error() and return None. each task can decide whether it can proceed without a repo_provider or not
• if NoConfiguredAppsAvailable, there are two ways to handle it:
  • if exc.rate_limited_count > 0, retry the task at the start of the next hour
  • otherwise, return None and each task can decide whether it can proceed without a repo_provider or not

i created codecov/engineering-team#3389 to keep track of moving usages of get_repo_provider_service() to this new method since there are many usages to move and some of them may prove to be non-trivial

[adrian-codecov]

In principle this looks good to me. I also think this should apply to get_owner_provider_service as it also calls the same fn. I believe Gio worked on this fn a while back so might be worth getting his opinion too

[matt-codecov]

I also think this should apply to get_owner_provider_service as it also calls the same fn

we can burn that bridge when we come to it haha

[codecov]

Codecov Report

Attention: Patch coverage is 96.72131% with 2 lines in your changes missing coverage. Please review.

Project coverage is 97.25%. Comparing base (74b3287) to head (94089b8).
Report is 2 commits behind head on main.

✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
tasks/base.py	92.30%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1107      +/-   ##
==========================================
- Coverage   97.25%   97.25%   -0.01%     
==========================================
  Files         454      454              
  Lines       37335    37392      +57     
==========================================
+ Hits        36310    36365      +55     
- Misses       1025     1027       +2     

Flag	Coverage Δ
integration	43.09% <31.14%> (-0.03%)	⬇️
unit	89.80% <96.72%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[codecov-notifications]

Codecov Report

Attention: Patch coverage is 96.72131% with 2 lines in your changes missing coverage. Please review.

✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
tasks/base.py	92.30%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!

[Swatinem]

I’m not a big fan of putting more methods onto the "celery task", but instead move more code out of the "celery as task scheduling framework".

I think the only reason for this to be tied to "celery as a framework" is converting the exception to a retry.

[sentry-io]

Suspect Issues

This pull request was deployed and Sentry observed the following issues:

• ‼️ InvalidInstallationError: permission_error app.tasks.upload.Upload View Issue
• ‼️ ConnectTimeout: HTTPSConnectionPool(host='api.github.com', port=443): Max retries exceeded with url: /app/installations/811488/access_tokens (Caused by ConnectTimeoutError(<urllib3.connection.HTTPSConnection object at 0x7f813a1ea350>, 'Connection to api.github.com time... app.tasks.upload.Upload View Issue
• ‼️ InterfaceError: connection already closed app.tasks.pulls.Sync View Issue
• ‼️ InterfaceError: connection already closed app.tasks.compute_comparison.ComputeComparison View Issue
• ‼️ InterfaceError: connection already closed app.tasks.upload.UploadProcessor View Issue

_{Did you find this useful? React with a 👍 or 👎}