-
Notifications
You must be signed in to change notification settings - Fork 28
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
feat: allow config for multi-apps #421
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅ 📢 Thoughts on this report? Let us know! |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #421 +/- ##
=======================================
Coverage 95.95% 95.95%
=======================================
Files 642 643 +1
Lines 16978 16999 +21
=======================================
+ Hits 16291 16312 +21
Misses 687 687
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
@@ Coverage Diff @@
## main #421 +/- ##
=======================================
Coverage 95.95% 95.95%
=======================================
Files 642 643 +1
Lines 16978 16999 +21
=======================================
+ Hits 16291 16312 +21
Misses 687 687
Flags with carried forward coverage won't be shown. Click here to find out more.
|
These changes introduce `OwnerInstallationNameToUseForTask` model. This model allows an `Owner` to configure a `installation_name` to be used for a given `task_name`. This can only be configured manually for now. That is on purpose as we want to test these changes first. context: codecov/engineering-team#1146 >⚠️ **These changes include a migration** > > Migration creates table for `OwnerInstallationNameToUseForTask`. > Should not be disruptive when deployed.
ee853c2
to
c27eede
Compare
("external_id", models.UUIDField(default=uuid.uuid4, editable=False)), | ||
("created_at", models.DateTimeField(auto_now_add=True)), | ||
("updated_at", models.DateTimeField(auto_now=True)), | ||
("installation_name", models.TextField()), |
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 just uses the name out of the app installations table? Any reason not to use a fk id?
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.
The reason might be ignorance on my part of how FKs work... 😅
My understanding is that it would connect an instance of OwnerInstallationName...
to 1 row in GithubAppInstallation
. That's not what I want.
But there can be many OwnerInstallationName...
that use the same installation_name
and one installation_name
can be used in multiple GithubAppInstallation
.
So there's no direct connection between this row of OwnerInstallationName...
and another row of GithubAppInstallation
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 what I was describing just to clarify. The way I understand it, a given task for an owner will only ever be assigned one GithubAppInstallation, either the default or a specific entry in your new table.
But there can be many OwnerInstallationName... that use the same installation_name and one installation_name can be used in multiple GithubAppInstallation.
I don't quite follow this statement. Happy to slack huddle too if you want to talk it out.
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.
Yes that makes perfect sense. That's not exactly the model I was working on though.
The difference is subtle, but the implication is essentially that it allows us to have this piece of code
It might be an overkill. But then you have "classes of apps" essentially (under a same name).
And they are all considered pretty equally when you select them for some task.
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.
am i understanding your idea right?
- partner creates a GitHub app named
"Codecov Notifications"
- partner creates an
OwnerInstallationNameToUseForTask
which saystasks.Notify
should use the app called"Codecov Notifications"
- they wind up hitting the rate limit even on their dedicated notifications app
- they create a distinct app, but they give it the same exact name
"Codecov Notifications"
- now we will automatically choose from 2
"Codecov Notifications"
apps without them having to configure anotherOwnerInstallationNameToUseForTask
if that's right, it does make the UX smoother for users when they are so big that a dedicated app for a task is still not enough and they need to add a second, third, fourth app
i don't have a strong opinion on whether the slightly-weird design here is worth it for the improvement. the alternative UX is not that bad (same steps + configuring another OwnerInstallationToUseForTask
), and afaik the need for this should be pretty rare, but if we add comments explaining this then the design isn't that strange
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.
Your understanding is correct Matt
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.
I think this implementation will work. Thanks for explaining it.
name="OwnerInstallationNameToUseForTask", | ||
fields=[ | ||
("id", models.BigAutoField(primary_key=True, serialize=False)), | ||
("external_id", models.UUIDField(default=uuid.uuid4, editable=False)), |
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.
remind me what external_id means, i know we use it elsewhere too
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.
All codecov base models include id
, external_id
, created_at
and updated_at
.
It is basically an ID for the object that we can share with users. A way to reference it that is not the actual ID
("external_id", models.UUIDField(default=uuid.uuid4, editable=False)), | ||
("created_at", models.DateTimeField(auto_now_add=True)), | ||
("updated_at", models.DateTimeField(auto_now=True)), | ||
("installation_name", models.TextField()), |
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.
am i understanding your idea right?
- partner creates a GitHub app named
"Codecov Notifications"
- partner creates an
OwnerInstallationNameToUseForTask
which saystasks.Notify
should use the app called"Codecov Notifications"
- they wind up hitting the rate limit even on their dedicated notifications app
- they create a distinct app, but they give it the same exact name
"Codecov Notifications"
- now we will automatically choose from 2
"Codecov Notifications"
apps without them having to configure anotherOwnerInstallationNameToUseForTask
if that's right, it does make the UX smoother for users when they are so big that a dedicated app for a task is still not enough and they need to add a second, third, fourth app
i don't have a strong opinion on whether the slightly-weird design here is worth it for the improvement. the alternative UX is not that bad (same steps + configuring another OwnerInstallationToUseForTask
), and afaik the need for this should be pretty rare, but if we add comments explaining this then the design isn't that strange
Codecov ReportAll modified and coverable lines are covered by tests ✅
Changes have been made to critical files, which contain lines commonly executed in production. Learn more Additional details and impacted files@@ Coverage Diff @@
## main #421 +/- ##
=======================================
+ Coverage 95.67 95.82 +0.15
=======================================
Files 764 758 -6
Lines 17564 17427 -137
=======================================
- Hits 16803 16699 -104
+ Misses 761 728 -33
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
These changes introduce
OwnerInstallationNameToUseForTask
model.This model allows an
Owner
to configure ainstallation_name
to beused for a given
task_name
. This can only be configured manually for now.That is on purpose as we want to test these changes first.
context: codecov/engineering-team#1146