Hi,

In The Edgent project we were using Travis. But the integration mode has 
changed. 
The legacy way worked, but you can no longer set it up and the new way requires 
privileges we can't give. 
At least I was told from infra when I asked to change the integration version 
to the new one.

Regarding Alex' question with bitcoin miners: It's a problem and they seem to 
have different strategies in detecting this, 
but this is quite a lot of work and is a permanent "hair and the hedgehog" race 
I would not want to force on the Infra guys.

Chris


Am 07.01.19, 16:54 schrieb "Joan Touzet" <woh...@apache.org>:

    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.
    

Reply via email to