-
Notifications
You must be signed in to change notification settings - Fork 23
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
Use a github action to centralize gin data preparation #1095
Conversation
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.
Looks good, this PR should probably delete update-s3-testing-data.yml to avoid confusion.
What possible confusion do you in mind? |
update-s3-testing-data.yml is disabled, and actions/load-data seems to be a replacement (is it not?), so we should delete update-s3-testing-data.yml to avoid maintaining vestigial workflows that aren't in use. |
No, it is not meant to replace it. This assumes the data is already on the s3 and loads it either from the cache or from the s3 if the former fails. At the moment we don't have a mechanism to automatically transfer the data from gin to s3. We should meet at brainstorm that. |
I see. update-testing-data.yml on roiextractors is more like load-data/action.yml than update-s3-testing-data.yml, so that's why I misunderstood.
gin is very finnicky, so we might just be better off keeping our current (manual) system. |
What troubles have you experienced? Not that I disagree. |
Failed downloads mostly. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1095 +/- ##
==========================================
+ Coverage 90.44% 90.58% +0.13%
==========================================
Files 129 129
Lines 8055 8164 +109
==========================================
+ Hits 7285 7395 +110
+ Misses 770 769 -1
Flags with carried forward coverage won't be shown. Click here to find out more. |
While working on #1013 I was having trouble getting the data right from the caches (see the diff in that PR). Centralizing the logic should make this kind of problem easier to deal with.
This is a partial move in the direction of #993.