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 | [email protected] On Wed, Dec 19, 2012 at 2:48 PM, Krinkle <[email protected]> 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 > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
