Re: Jenkins jobs to verify patches

[Jim Apple <jb...@cloudera.com>]

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 <ta...@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 <jb...@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.
>>

Re: Jenkins jobs to verify patches

[Jim Apple <jb...@cloudera.com>]

As discussed in the thread, requiring the use of gerrit provides an
auditing method - the code must at least be posted there, so if
something goes haywire we can see the code that caused it.

However, you can post a draft if the code is not yet ready for review.
the Jenkins job can test your draft.

On Thu, Jan 5, 2017 at 4:13 AM, Lars Volker <lv...@cloudera.com> wrote:
> Is it possible without much effort to make this work on github urls, too?
> Currently our policy seems to be that we pick up reviews as soon as they're
> posted, so there doesn't seem to be a way for non-Cloudera non-committers
> to run tests on Jenkins before submitting a change for review.
>
> On Thu, Jan 5, 2017 at 3:02 AM, Jim Apple <jb...@cloudera.com> wrote:
>
>> http://jenkins.impala.io:8080/job/pre-review-test/ is now open for
>> business.
>>
>> On Tue, Jan 3, 2017 at 3:53 PM, Jim Apple <jb...@cloudera.com> wrote:
>> > 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 <ta...@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 <jb...@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.
>> >>>
>>

Re: Jenkins jobs to verify patches

[Lars Volker <lv...@cloudera.com>]

Is it possible without much effort to make this work on github urls, too?
Currently our policy seems to be that we pick up reviews as soon as they're
posted, so there doesn't seem to be a way for non-Cloudera non-committers
to run tests on Jenkins before submitting a change for review.

On Thu, Jan 5, 2017 at 3:02 AM, Jim Apple <jb...@cloudera.com> wrote:

> http://jenkins.impala.io:8080/job/pre-review-test/ is now open for
> business.
>
> On Tue, Jan 3, 2017 at 3:53 PM, Jim Apple <jb...@cloudera.com> wrote:
> > 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 <ta...@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 <jb...@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.
> >>>
>

Re: Jenkins jobs to verify patches

[Jim Apple <jb...@cloudera.com>]

http://jenkins.impala.io:8080/job/pre-review-test/ is now open for business.

On Tue, Jan 3, 2017 at 3:53 PM, Jim Apple <jb...@cloudera.com> wrote:
> 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 <ta...@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 <jb...@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.
>>>