On 01/03/2014 09:16 AM, Itamar Heim wrote:
On 01/03/2014 09:54 AM, Eyal Edri wrote:
> not sure, the results are created from the src code, and if the same job checksout
diff patches to the same place that can create the fp errors we see now..
> deleting the results will just mean they will be created again the same...
the job doesn't 'diff patches', it uses git which cleans up the source
part of the workspace.
the problem seems to be with residual findbug files not overwritten
Findbugs doesn't analyze source code, it analyzes the generated
bytecode, the .class files. It then uses the line number information
embedded in the .class and the source files to generate the reports.
This job generates the reports finding all the findbugsXml.xml that are
available in the source tree. See these lines in one of the jobs:
FINDBUGS] Collecting findbugs analysis files...
[FINDBUGS] Finding all files that match the pattern **/findbugsXml.xml
[FINDBUGS] Parsing 26 files in
/home/jenkins/workspace/ovirt_engine_master_find_bugs_gerrit
[FINDBUGS] Successfully parsed file
/home/jenkins/workspace/ovirt_engine_master_find_bugs_gerrit/ovirt-engine/backend/manager/modules/authentication/target/findbugsXml.xml
of module with 1 warnings.
So what happens here is that there are findbugsXml.xml files from
previous builds in the source tree. I would suggest to clean the source
tree with (with "git clean -dfx", for example) before starting the job.
>
> On Jan 3, 2014 9:42 AM, Itamar Heim <iheim(a)redhat.com> wrote:
>>
>> On 01/03/2014 08:58 AM, Eyal Edri wrote:
>>> The obvious is toOn 01/03/2014 08:58 AM, Eyal Edri wrote:
>> The obvious is to enable wipe workspace per run, but i fear that will be
>> add much more run time per patch and that jenkins won't be able to handle
the
>> queue of jobs, but it's worth a try.
>>
>> i will enable it for now, and we'll monitor the queue size.
>
> I don't think you need to clean the entire workspace, just the findbugs
> results, which are probably showing results of a class no longer there.
>
>>
>> eyal.
>>
>> ----- Original Message -----
>>> From: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
>>> To: "Moti Asayag" <masayag(a)redhat.com>
>>> Cc: "engine-devel" ovirt.org>
>>> Sent: Friday, January 3, 2014 7:39:45 AM
>>> Subject: Re: [Engine-devel] Strange findbugs warning for a phantom class
>>>
>>> I saw this today as well - findbugs showed new warnings for jsonrpc java
>>> client code , but my patches are not rebased against that work (the jsonrpc
>>> code is not merged to master).
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
>>>> To: "Moti Asayag" <masayag(a)redhat.com>
>>>> Cc: "engine-devel" ovirt.org>
>>>> Sent: Thursday, January 2, 2014 11:54:28 PM
>>>> Subject: Re: [Engine-devel] Strange findbugs warning for a phantom class
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Moti Asayag" <masayag(a)redhat.com>
>>>>> To: "engine-devel" ovirt.org>
>>>>> Sent: Thursday, January 2, 2014 7:40:47 PM
>>>>> Subject: [Engine-devel] Strange findbugs warning for a phantom class
>>>>>
>>>>> It seems that findbugs complains [1] about a class which never
>>>>> existed in ovirt-engine (a job which is run per pushed patch):
>>>>>
>>>>> org.ovirt.engine.core.authentication.tls.TlsSocketFactoryN
>>>>
>>>> I can only say what is the source of this class - the AAA rewrite Juan
and
>>>> I
>>>> are working on.
>>>>>
>>>>> This produces too much noise in gerrit. I'm not sure what is the
>>>>> origin of the class, but i was under the assumption that findbugs
>>>>> should be run for each patch on a clean env, without leftovers
>>>>> from job on other patches.
>>>>>
>>>>> Any idea how to clear this class/error ?
>>>>
>>>> +1 on Moti's question - I think I saw this behavior last week as
well.
>>>>
>>>>>
>>>>> [1]
>>>>>
http://jenkins.ovirt.org/job/ovirt_engine_master_find_bugs_gerrit/3269/fi...
>>>>>
>>>>> Thanks,
>>>>> Moti
>>>>>
--
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.