Sounds good to me. IMHO, if you're submitting a patch and haven't already run unit tests on that patch, you're probably doing something wrong. I've done that a few times myself, and could have avoided unnecessary patchset submissions if I had done so.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Wed, Dec 19, 2012 at 2:48 PM, Krinkle krinklemail@gmail.com wrote:
Hello,
We would like to clarify the reason we changed Jenkins to no longer run unit tests on patch submission.
We had to defer code execution to after CR+2 for security reasons. If unit tests were ran on submission that meant anyone with a labs account could effectively get shell access on the server.
Because LDAP accounts are now up for open registration (aka free Labs accounts, and by extend permission to submit patches to Gerrit), that also meant the whole world would be able to get shell access on the server (via PHP/Nodejs/ant/bash to infinity and beyond).
This issue will be definitely solved by isolating tests in dedicated virtual machines for each run. We are investigating Vagrant.
Restricting unit tests is simpler and faster to implement over all the Vagrant engineering. So "running tests after CR+2" is a temporary measure until the implementation of Vagrant sandboxes in Jenkins builds is ready.
So, in conclusion: Unit tests will be run again on patch submission once we have finished integrating Vagrant in Jenkins.
-- The CI team Antoine & Timo
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l