[Engine-devel] Minor change in the per patch process.

[Robert Middleswarth]

On 08/19/2012 11:50 AM, Dan Kenigsberg wrote:
> On Sun, Aug 19, 2012 at 04:06:09AM -0400, Robert Middleswarth wrote:
>> On 08/19/2012 03:21 AM, Dan Kenigsberg wrote:
>>> On Thu, Aug 16, 2012 at 09:32:20PM -0400, Robert Middleswarth wrote:
>>>> Part of the process now include creating rpm packages.
>>>> http://jenkins.ovirt.info/view/patches/job/patch_engine_create_rpms/
>>>> This allows people to download and test packages based on the change
>>>> if they want to.
>>> I wonder if this is needed by people. For me it duplicates the number of
>>> emails per change...
>>>
>>> BTW, I see that a failed job http://jenkins.ovirt.info/job/patch_vdsm_unit_tests/486/console
>>> does not set V-1 on the change. Could this be fixed? I'd like the poster
>>> and human reviewer to be perfectly aware that a change breaks unit
>>> tests.
>>>
>>> Regrads,
>>> Dan.
>> This was detailed in an earlier email.
> I'm sorry that I've missed it.
>
>> There are limits related to
>> the current plugin and how it processes patches.  The issue is
>> simple and effects job when aborted because someone isn't in the
>> whitelist.  I have spent a lot of time testing diff options and the
>> best I could come up with is that we abort the process.  The biggest
>> problem is the gerrit-trigger plugin treats aborts as if they are a
>> failure instead of as a non event.  I tried several diff ways to
>> make it a non event but couldn't find one.  The choice I went with
>> was to add text that they failed and leave them at zero the other
>> options was to mark all failure / aborts (Including people not in
>> the whitelist) as a -1 that wasn't really acceptable.  There are 2
>> diff bug reports and if either gets fixed we will be able to -1
>> failures but until the are done I am very limited on the options.
> We'll make with what we've got. Thanks.
>
> Oh, and a tiny "security" comment: we may trust infallible at engineer.org
> but not her fallible at engineer.org colleague. So grep'ing the
> whitelist should be done with something like
>
>    grep -q ^${email}$
Point taken and grep line tested and changed.

-- 
Thanks
Robert Middleswarth
@rmiddle (twitter/IRC)