-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
chore(integrations): register integration domains in initializer #80212
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is ✅ All tests successful. No failed tests found.
Additional details and impacted files@@ Coverage Diff @@
## master #80212 +/- ##
==========================================
- Coverage 78.08% 78.08% -0.01%
==========================================
Files 7179 7179
Lines 317130 317148 +18
Branches 43724 43727 +3
==========================================
+ Hits 247637 247639 +2
- Misses 63148 63158 +10
- Partials 6345 6351 +6 |
@@ -311,6 +311,7 @@ def search_issues(self, query: str | None, **kwargs) -> dict[str, Any]: | |||
class GitHubIntegrationProvider(IntegrationProvider): | |||
key = "github" | |||
name = "GitHub" | |||
domain = IntegrationDomain.SOURCE_CODE_MANAGEMENT |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is definitely a bit nicer. Tying the domain to the provider class really solidifies what an integration's responsibility is at instantiation time. I also remember @ameliahsu mentioning turning this into an array, which should work for the multiple domains on a single integration problem, but is the issue that we need a single "primary" domain per integration?
self.__integration_domains: dict[str, IntegrationDomain] = ( | ||
{} | ||
) # map of integration to domain |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor nit: I think it's fine to generate this on the fly from the list of integration providers instead of storing it on the class. I don't think it'll add too much overhead and reduces our need to remove them when something unregisters.
@@ -36,6 +43,9 @@ def exists(self, key: str) -> bool: | |||
|
|||
def register(self, cls: type[IntegrationProvider]) -> None: | |||
self.__values[cls.key] = cls | |||
if cls.domain: | |||
self.__domain_integrations[cls.domain].append(cls.key) | |||
self.__integration_domains[cls.key] = cls.domain | |||
|
|||
def unregister(self, cls: type[IntegrationProvider]) -> None: | |||
try: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you do decide to keep the domain dictionaries around, you'll need to remove integrations from them here.
Instead of hardcoding the integration domains and their keys, we can specify the
domain
inside each respectiveIntegrationProvider
. When the provider gets registered ininitializer.py
, we can dynamically construct the mapping of domains to keys, and vice versa.domain
is optional as there are some integrations that we haven't classified yet. If/when we emit metrics, we can classify these under "unknown".