Onboarding and supporting customers with 10k files

[aj-codecov]

Problem to Solve: _____ really wants to use components, because they have a massive monolith Supporting all the components they need would basically be a 30,000+ lines long codecov.yml

Proposed Solution: There is a CODEOWNERS file where each line basically looks like: /some/file/or/folder/path @teamName @featureArea They use this to keep a running list of files and folders and who owns them. They want to map this to components We could do something like: /some/file/or/folder/path @codecov:component:component_name and essentially that path/@ combo becomes a component in our system with the name component_name. If you want to actually set custom rules for that component around coverage or whatever, you still have to do that in the yaml, but if you just want a grouping for filtering and stuff in the UI, that should be enough.

### Tasks
- [ ] https://github.com/codecov/engineering-team/issues/1739

[michelletran-codecov]

@aj-codecov After doing some testing, adding the tag breaks the GitHub functionality if you add the @codecov:component:component_name tag to the same line as the actual owners. Therefore, our users will need to add a separate line to map the component to preserve the GitHub functionality. This would mean that a 30000 line CODEOWNERS will potentially be double for a user (depending on how many components they want to add). This usage feels kind of unintuitive, so I'm wondering if this is still OK.

AFAICT, this is an undocumented use of Codeowners, so if GitHub changes it's parsing so that the file fails to get Codeowners after the first unparseable line, then our customers might have broken Codeowners capability.

If we are going down the route of needing a new line for each component anyways, should we maybe just consider adding a condensed representation for components instead?

[michelletran-codecov]

I had a meeting with @vlad-ko and @rohan-at-sentry today, and it seems like there were a few misunderstandings. We are not necessarily creating 10,000 components, but rather we want to parse 10,000 lines into X number of components (which will be probably significantly less than 10,000). I think we've agreed that using CODEOWNERs (as suggested by this ticket) is probably not going to work. We can investigate whether we want to use the CODEOWNERs directly (with filepath as component name). However, we've also recognized that this request is probably low priority because it's not blocking current business opportunities.

[thomasrockhu-codecov]

Deprioritizing due to unclear requirements, need to scope out better what the use case is