-
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
prune docker containers (continuously) #37
prune docker containers (continuously) #37
Conversation
theoretically, but they are now in the same chunk, so I don't think that's a problem. |
So you think of starting an infinite loop like the following at the beginning of the test job (not sure about the sleep):
The advantage would be to have only one Galaxy startup. Also wondering
I guess we do not have to consider workflow tests since those take the images from CVMFS? |
Active images aren't deleted. If disk space becomes an issue we can always tell the interactor to purge histories. sleep 60 seems fine. Only tool data comes from CVMFS. |
otherwise the 1st job does not profit from this
fa5f84b
to
88ae1d8
Compare
bf7f535
to
9302ac1
Compare
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.
Let's do it! Then we can also drop the for loop in the action and just run a single galaxy process for all tool tests.
Can do. But then we should also purge histories after tests? or is this already done? |
I don't think it is, but I think that'd be a good option. Maybe we should have a CI profile in planemo that collects all those options. FYI galaxy-tool-test has a bunch of relevant options we should also expose in planemo:
|
OK. Then I would leave it as is and prepare a new release if you agree. I filed an issue for the history options galaxyproject/planemo#1380 |
Sounds good, thank you! |
otherwise the 1st job does not profit from this
There was a recent discussion with @mvdbeek (galaxyproject/tools-iuc#4935 (comment)) to do this in a loop running in the background. I thought about this: I think the problem is that the containers would be pruned also inbetween tests of the same tool / tool repo with the same requirements (and therefore the same container).