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(a)gmail.com
On Wed, Dec 19, 2012 at 2:48 PM, Krinkle <krinklemail(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l