----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Robert Middleswarth" <robert(a)middleswarth.net>
Cc: infra(a)ovirt.org
Sent: Wednesday, August 1, 2012 5:01:10 PM
Subject: Re: Security issues when running gerrit patches on jenkins
On 08/01/2012 04:56 PM, Robert Middleswarth wrote:
> On 08/01/2012 09:50 AM, Ewoud Kohl van Wijngaarden wrote:
>> On Wed, Aug 01, 2012 at 09:35:39AM -0400, Robert Middleswarth
>> wrote:
>>> On 08/01/2012 09:31 AM, Eyal Edri wrote:
>>>> Itamar Heim wrote:
>>>>> wouldn't it be easier to maintain the whitelist via a git repo
>>>>> on
>>>>> gerrit?
>>>> you mean instead of putting it on a wiki page?
>>>> yes, make sense to maintain a .txt file per project with the
>>>> whitelist in it.
>>> Actually makes a lot more since. That allows the projects the
>>> ability to manage there own list.
>> Can't we extract this from an authors file? Looking at
>> vdsm/AUTHORS[1]
>> it looks fairly easy.
> That would be a bad idea. All someone would need to do is add
> themselves to that list?
>>
lets start with something... worst case someone will send a patch
without jenkins auto reviewing it once or twice - important thing is
it
will get 99.9% of the patches reviewed by jenkins
OK. i opened a feature request for it here [1]
for now i imagine we can implement it with some bash code in a jenkins job,
and we can also try to send a patch for it to the gerrit trigger plugin [2]
[1]
https://issues.jenkins-ci.org/browse/JENKINS-14655
[2]
https://github.com/jenkinsci/gerrit-trigger-plugin
>> Another thing I can imagine is that someone is not whitelisted but
>> his/her patch receives recieves a +1 from a whitelisted reviewer
>> it can
>> be built as well. It would be built anyway if it gets accepted and
>> now
>> jenkins can give -1 if it fails unit tests. Maybe at +2, but that
>> leaves
>> very little time to actually build it because often it will get
>> merged
>> straight away.
> That does sound useful once someone not on the white list gets a +1
> it
> auto test as we can assume anyone reviewing is trusted enough to
> not +1
> a dangerous patch. Of curse this adds even more complexity in a
> plug-in. Although not specific enough to make the plug-in not
> reusable.
>> [1]:
>>
http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=AUTHORS;hb=HEAD
>> _______________________________________________
>> Infra mailing list
>> Infra(a)ovirt.org
>>
http://lists.ovirt.org/mailman/listinfo/infra
>
>
_______________________________________________
Infra mailing list
Infra(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra