-
Notifications
You must be signed in to change notification settings - Fork 10
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
Worker: Migrate to Plan / Tier Tables #1007
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅ ✅ All tests successful. No failed tests found. 📢 Thoughts on this report? Let us know! |
❌ 2 Tests Failed:
View the top 2 failed tests by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
❌ 2 Tests Failed:
View the top 2 failed tests by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
✅ All tests successful. No failed tests were found. 📣 Thoughts on this report? Let Codecov know! | Powered by Codecov |
Codecov ReportAll modified and coverable lines are covered by tests ✅
✅ All tests successful. No failed tests found. Additional details and impacted files@@ Coverage Diff @@
## main #1007 +/- ##
=======================================
Coverage ? 97.52%
=======================================
Files ? 462
Lines ? 37899
Branches ? 0
=======================================
Hits ? 36960
Misses ? 939
Partials ? 0
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
types.String(50), nullable=False, default=PlanName.BASIC_PLAN_NAME.value | ||
types.String(50), | ||
nullable=False, | ||
default=PlanName.BASIC_PLAN_NAME.value, # TODO: UPDATE WITH NEW FREE PLAN NAME |
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.
Good catch!
This PR includes changes to |
@@ -491,12 +500,14 @@ def test_get_decoration_type_not_pr_plan(self, dbsession, mocker, enriched_pull) | |||
assert decoration_details.reason == "Org not on PR plan" | |||
assert decoration_details.should_attempt_author_auto_activation is False | |||
|
|||
@pytest.mark.django_db | |||
# what is a users plan? |
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.
users plan is the one from GHM, which we actually will need to add to the plan table in DB as well now that I think about it
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.
oohhh cool cool
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.
Thanks for cleaning up all that print noise in test code (and in production code, lol). If its not too much effort, can you extract those changes as a separate PR?
Otherwise, my comments related to having this mock data around globally instead of pulling it in explicitly. As well as consuming these objects from the DB rather than by mocking function calls would be nice.
Mixing django/sqlalchemy is also something to be cautious about, as I believe it could cause massive problems.
@patch("services.notification.Plan.objects.get") | ||
def test_should_use_checks_notifier_deprecated_flow( | ||
self, repo_data, outcome, dbsession | ||
self, plan_objects_get, repo_data, outcome, dbsession | ||
): | ||
plan = PlanFactory.create() | ||
plan_objects_get.return_value = plan |
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 have some questions, and see some problems with this:
- first of all, you are creating the entity based on the Factory, so you might as well instert this into the database instead of using a mock for it.
- but judging by the mock, this looks like you are using django
.objects.get
somewhere internally. This does not mix well with sqlalchemy (judging by both thedbsession
fixture, and the.create
test factory.
I believe that also in production, we should not mix these two ORMs, as that can potentially cause deadlocks.
from shared.plan.constants import PlanName, PlanPrice, TierName | ||
|
||
|
||
def mock_all_plans_and_tiers(): |
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.
you are calling this explicitly in a ton of tests.
How is this being handled in production? Were these things created manually, or using a data migration?
Maybe it makes sense to introduce these kinds of "constants" using a data migration in the first place.
Otherwise, is it possible to auto-load these fixtures in all the tests that are using the django DB somehow?
Its a bit annoying that you have to call this manually in all those places. Better to just "have this data around" within your tests.
This PR includes changes to |
This PR includes changes to |
The main objective of this PR is to migrate all Backend Service logic to use the new plan and tiers tables instead of the Plan constants. You can read more about milestone 3 here.
A core change introduced in this PR is the creation of mocks for plans and tiers, which are used in most test setup functions. For tests requiring usage in all nested functions, we use a fixture with autouse enabled. Additionally, we ensure django_db decorators are included to allow access to the mock database.
The rest of the changes should be fairly straightforward.
Closes codecov/engineering-team#3253
Legal Boilerplate
Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. In 2022 this entity acquired Codecov and as result Sentry is going to need some rights from me in order to utilize my contributions in this PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.