-
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
ref: Refactor upload task to accomodate multiple report types #190
Conversation
Codecov Report
@@ Coverage Diff @@
## main #190 +/- ##
==========================================
- Coverage 98.34% 98.33% -0.02%
==========================================
Files 351 351
Lines 27721 27763 +42
==========================================
+ Hits 27262 27300 +38
- Misses 459 463 +4
Flags with carried forward coverage won't be shown. Click here to find out more.
|
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #190 +/- ##
==========================================
- Coverage 98.33% 98.32% -0.02%
==========================================
Files 358 358
Lines 28869 28923 +54
==========================================
+ Hits 28389 28438 +49
- Misses 480 485 +5
Flags with carried forward coverage won't be shown. Click here to find out more.
|
Codecov Report
Changes have been made to critical files, which contain lines commonly executed in production. Learn more Additional details and impacted files@@ Coverage Diff @@
## main #190 +/- ##
==========================================
- Coverage 98.30% 98.29% -0.02%
==========================================
Files 389 389
Lines 29565 29620 +55
==========================================
+ Hits 29064 29114 +50
- Misses 501 506 +5
Flags with carried forward coverage won't be shown. Click here to find out more.
|
I like this idea in general. I think that if we can re-use the entry point of uploads processing it's gonna be a positive thing. The refactor itself was very good. Special thanks to the helpful TODO comments. |
Thanks for taking a look @giovanni-guidini. I agree that |
* main: Only trigger AI PR review if pull is open Add log line when triggering AI PR review task fix: use original PR base to compute patch coverage (#199) Prepare release 23.12.4 Update workflows chore(deps): Update codecov-shared dependency (#194) Prep the terrain for reports with label compression. (#188) allow staging deploy when pushing to staging (#192)
Codecov Report
@@ Coverage Diff @@
## main #190 +/- ##
==========================================
- Coverage 98.33% 98.32% -0.02%
==========================================
Files 358 358
Lines 28869 28923 +54
==========================================
+ Hits 28389 28438 +49
- Misses 480 485 +5
Flags with carried forward coverage won't be shown. Click here to find out more.
|
This is ready for a proper review now. After some discussion we decided that this was indeed the path forward that we're going to take for handling other types of uploads. I made the migration to add the new There's TODOs where the other types of ingest can be handled. @joseph-sentry and I can plug in our adapters for test results and bundle analysis there but I figured it'd be good to get this merged and tested to make sure the existing behavior is not changed for coverage uploads. |
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.
approving this, but I think in the future we should separate the checkpoint logger upload flows for each report type
I could just begin the existing checkpoint flow only for |
This is a proposal for how we could potentially handle the ingest of multiple types of upload. It assumes we're reusing the existing
CommitReport
model and adding a newreport_type
column to that table. Existing behavior should be unchanged (forreport_type = "coverage"
, the default) and allows us to reuse much of the ancillary support behavior that the upload task currently provides (fetching commit info, all the locking around processing, etc.).When
report_type = "coverage"
we create our regular chain of tasks (upload processor -> finisher -> notify) but we would likely trigger other (new) tasks to handle the processing and notification related to other types of ingests.I noticed that we were passing around
repoid
+commitid
+report_type
+report_code
a lot so I also refactored that into a new class calledUploadArgs
which encapsulates these (together with the arguments that are passed to the task via Redis).The existing
ReportService
has some generic methods (like creating/retrieving uploads) but we'd want to create different adapters for each report type. I left some comments in the code about specific interfaces we're currently relying on.