The Jenkins community itself runs PR verification builds on all PRs to Jenkins core and plugins. These PRs are built on the ci.jenkins.io but it only uses disposable build agents (single-shot provisioned on Azure on demand thanks to a grant from Microsoft)
On 2019/01/06 23:53:44, Alex Harui <aha...@adobe.com.INVALID> wrote: > What other organizations are running a similar patch/pr Jenkins capability > and how do they implement "security" to prevent exploits like bitcoin miners > and other attacks? > > IMO, if you give free compute resources, the bad people will eventually > figure out how to use it to their advantage. > > -Alex > > On 1/6/19, 10:52 AM, "Allen Wittenauer" <a...@effectivemachines.com.INVALID> > wrote: > > > > > On Jan 6, 2019, at 10:43 AM, Dominik Psenner <dpsen...@gmail.com> wrote: > > > > On Sun, Jan 6, 2019, 19:32 Allen Wittenauer > > <a...@effectivemachines.com.invalid wrote: > > > >> > >> 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] > >> > > > > If some project build begins to draw resources in an extraordinary > fashion > > it will be noticed. > > Strongly disagree. My cleaner code killed three stuck surefire jobs > that had been looping on a handful of cores since sometime in 2018 yesterday. > The sling jobs I noted earlier in the week had 20GB of RAM. That’s even > before we get into the unit-tests-that-are-really-integration-tests that are > coming from the big data projects where gigs of memory and thousands of > process slots are consumed on a regular basis. > >
