See travis-ci.org.
This is the model we could be emulating.
----- Original Message -----
From: "Alex Harui" <aha...@adobe.com.INVALID>
To: builds@apache.org
Sent: Sunday, January 6, 2019 6:53:44 PM
Subject: Re: PRJenkins builds for Projects
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.
