You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems that the /tmp directory can fill up fairly quickly when multiple people are running various tasks. From what I understand, Semaphore appears to create a separate Python virtual environment for each task and then clones the necessary repositories for that environment.
Over time, this can take up significant space on the host, especially if the repositories are large.
I was wondering if there might be a way to clean up the /tmp directory used by Python virtual environments after a successful run. For tasks that are scheduled, I imagine this wouldn't need to be part of the garbage collection process, since it would require extra bandwidth. Each time a scheduled task runs, it would recreate the virtual environment and redownload the repositories anyway.
Implementation
A possible solution, would be that the virtual env. is removed after a successful run.
Design
No response
The text was updated successfully, but these errors were encountered:
Related to
Other
Impact
better user experience
Missing Feature
It seems that the /tmp directory can fill up fairly quickly when multiple people are running various tasks. From what I understand, Semaphore appears to create a separate Python virtual environment for each task and then clones the necessary repositories for that environment.
Over time, this can take up significant space on the host, especially if the repositories are large.
I was wondering if there might be a way to clean up the /tmp directory used by Python virtual environments after a successful run. For tasks that are scheduled, I imagine this wouldn't need to be part of the garbage collection process, since it would require extra bandwidth. Each time a scheduled task runs, it would recreate the virtual environment and redownload the repositories anyway.
Implementation
A possible solution, would be that the virtual env. is removed after a successful run.
Design
No response
The text was updated successfully, but these errors were encountered: