-
Notifications
You must be signed in to change notification settings - Fork 5
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
535 singularity #540
535 singularity #540
Conversation
…fore pushing the image 👠" This reverts commit a828dfd.
… be less error-prone 😷
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #540 +/- ##
==========================================
- Coverage 65.72% 64.74% -0.99%
==========================================
Files 48 48
Lines 4537 4686 +149
==========================================
+ Hits 2982 3034 +52
- Misses 1555 1652 +97 ☔ View full report in Codecov by Sentry. |
…ction-calling purpose 🎼
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.
Very well-written code, only a few small comments about documentation and a few methods.
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.
💯
closes #535
This PR addresses the issues of #535 . The main work was to make sure, that the disk-caching was not performed in a read-only filesystem, since in Singularity you're not the same user as the creator of the image. Therefore, I refactored
FileHandler
to have a short-term-memory and long-term-memory disk-cache available. Long-term is mainly for downloaded objects, where short-term-memory is for intermediate data-products, if no file/dir-path was provided in the according API-function. For details, see code & docstring ofFileHandler
.In addition, I've seen two instances where I was not happy how it was implemented (in addition with the disk-caching), and saw a good opportunity to refactor the code. The first one was, how
DaskHandler
was implemented. It had some twisted code with SLURM, where the separation of concerns was not fulfilled. In addition, I've refactored some telescope-function code to be increase the stability & re-usability of the code.This PR should be merged after #526 is merged, because it's a branch created from
512_sarus
.The testing-setup was, I tested our tests in singularity- sarus & docker-container, and they passed there. This is of course no guarantee that I got everything, however, I've looked through the entire repository & the tests passed which is good enough I think.