Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign up45216 continuousbenchmarking nuketmp 20161006 5 #2298
Conversation
ashawnbandy-te-tfb
added some commits
Sep 30, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
knewmanTE
Oct 6, 2016
Contributor
Could this cause any problems for users who aren't running the testing suite in an isolated VM?
|
Could this cause any problems for users who aren't running the testing suite in an isolated VM? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ashawnbandy-te-tfb
Oct 6, 2016
Contributor
That's a really good question. The short answer is "Yes, but really it shouldn't." This will only remove files out of /tmp that are owned (or otherwise writable) by the user that is running benchmarker.py. We should probably document this in the setup instructions for the suite.
|
That's a really good question. The short answer is "Yes, but really it shouldn't." This will only remove files out of /tmp that are owned (or otherwise writable) by the user that is running benchmarker.py. We should probably document this in the setup instructions for the suite. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
knewmanTE
Oct 6, 2016
Contributor
@ashawnbandy-te-tfb document telling users that they should be running in an isolated environment, or telling users that it will only be deleting tmp files owned by testrunner?
|
@ashawnbandy-te-tfb document telling users that they should be running in an isolated environment, or telling users that it will only be deleting tmp files owned by testrunner? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ashawnbandy-te-tfb
Oct 6, 2016
Contributor
I would say probably a caution that one should not use one's regular user to run tests in an environment where erasing files out of /tmp would be a problem. The worst case should not be all that bad: /tmp is meant to be temporary in nature.
|
I would say probably a caution that one should not use one's regular user to run tests in an environment where erasing files out of /tmp would be a problem. The worst case should not be all that bad: /tmp is meant to be temporary in nature. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ashawnbandy-te-tfb
Oct 7, 2016
Contributor
@knewmanTE suggested adding a command line switch to turn on this feature (i.e. by default no files are removed). I will add that and re-open this PR when it is complete.
|
@knewmanTE suggested adding a command line switch to turn on this feature (i.e. by default no files are removed). I will add that and re-open this PR when it is complete. |
ashawnbandy-te-tfb
closed this
Oct 7, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
knewmanTE
Oct 7, 2016
Contributor
@ashawnbandy-te-tfb you can also just add "WIP" to the title of the task to indicate that it is a work in progress!
|
@ashawnbandy-te-tfb you can also just add "WIP" to the title of the task to indicate that it is a work in progress! |
ashawnbandy-te-tfb commentedOct 6, 2016
As it stands currently, many frameworks are writing to /tmp. So many, in fact, that in our testing environment the pool of inodes are exhausted which causes tests needing to write anything to fail. This commit introduces work to remove files that are generated by a test after that test is done. Note: there is no attempt to remove all files from /tmp (i.e. sudo is not used, nor is the search recursive).