impala-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Apple <jbap...@cloudera.com>
Subject Re: Jenkins jobs to verify patches
Date Tue, 03 Jan 2017 23:53:07 GMT
Given that sentiment, I'll plan on opening up a limited-parallelism
job for anonymous users that only allows gerrit patches.

I will also plan the switchover to happen on January 9, six days from
today. On that day, I'll turn off the Cloudera-VPN-gated pre-merge
job.

On Wed, Dec 14, 2016 at 9:12 AM, Tim Armstrong <tarmstrong@cloudera.com> wrote:
> Got it.
>
> I think I'd probably be more in favour of handing out login credential to
> contributors on demand (e.g. by mailing a list)  rather than having open
> access, just so we have a clearer idea of who's using it. I don't have a
> strong objection to the alternative.
>
> On Wed, Dec 14, 2016 at 8:52 AM, Jim Apple <jbapple@cloudera.com> wrote:
>
>> > How isolated is the Jenkins instance?
>>
>> As far as I know, the workers have little access to the coordinator. See
>> here:
>>
>> https://wiki.jenkins-ci.org/display/JENKINS/Slave+To+Master+Access+Control
>>
>> This flag is on and there are no whitelisted exceptions.
>>
>> > Does the jenkins user have many privileges on the VM?
>>
>> They have passwordless sudo on the worker
>>
>> > Could it simply wipe
>> > out the job history to destroy the trail?
>>
>> Job history is stored on the coordinator.
>>
>> > Jenkins also presumably has
>> > credentials to make at least some changes to gerrit - are those
>> privileges
>> > restrictive enough that it couldn't cause problems there too?
>>
>> Those are stored only on the coordinator and cannot be used by the slaves.
>>

Mime
View raw message