a) The ASF has been running untrusted code since before Github existed. From my casual watching of Jenkins, most of the change code we run doesn’t come from Github PRs. Any solution absolutely needs to consider what happens in a JIRA-based patch file world. [footnote 1,2]
b) Making everything get reviewed by a committer before executing is a non-starter. For large communities, precommit testing acts as a way for contributors to get feedback prior to a committer even getting involved. This allows for change iteration prior to another human spending time on it. But the secondary effect is that it acts as a funnel: if a project gets thousands of change requests a year [footnote 3], it’s now trivial for committers to focus their energy on the ones that are closest to commit. c) We’ve needed disposable environments (what Stephen Connolly called throwaway hardware and is similar to what Dominik Psenner talked about wrt gitlab runners) for a while. When INFRA enabled multiple executors per node (which they did for good reasons), it triggered an avalanche of problems: maven’s lack of repo locking, noisy neighbors, Jenkins’ problems galore (security and DoS which still exist today!), systemd’s cgroup limitations, and a whole lot more. Getting security out of them is really just extra at this point. ==== 1 - With the forced moved to gitbox, this may change, but time will tell. 2 - FWIW: Gavin and I have been playing with Jenkins’ JIRA Trigger Plugin and finding that it’s got some significant weaknesses and needs a lot of support code to make viable. This means we’ll likely be sticking with some form of Yetus’ precommit-admin for a while longer. :( So the bright side here is that at least the ASF owns the code to make it happen. 3 - Some perspective: Hadoop generated ~6500 JIRAs with patch files attached last year alone for the nearly 15 or so active committers to review. If half of the issues had the initial patch plus a single iteration, that’s 13,000 patches that got tested on Jenkins.
