[infinispan-dev] build failures on jenkins

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] build failures on jenkins

Sanne Grinovero-3
Hi,
it seems that the Infinispan-lucene-master task relies on deployed
snapshots of core, and since there aren't any for 5.1, it's failing.

https://infinispan.ci.cloudbees.com/job/Infinispan-lucene-master-TRACE/73/changes

So even if I deploy a snapshot, it means the tests are always run
against an older core version, whatever happened to be deployed,
instead of reporting about the last version.

Would it be reasonable to have the primary job
(Infinispan-master-JDK6-tcp) deploy snapshots at each execution? I'd
like it to deploy to jboss.org, but it might generate quite some load
and would need us to give him permissions.
I see there is an option "Deploy artifacts to my Private CloudBees
Repository", not sure if we have such a thing, nor if the secondary
module will find it from there.

Cheers,
Sanne
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] build failures on jenkins

Manik Surtani
Galder, any thoughts on this?

On 2 Aug 2011, at 15:43, Sanne Grinovero wrote:

> Hi,
> it seems that the Infinispan-lucene-master task relies on deployed
> snapshots of core, and since there aren't any for 5.1, it's failing.
>
> https://infinispan.ci.cloudbees.com/job/Infinispan-lucene-master-TRACE/73/changes
>
> So even if I deploy a snapshot, it means the tests are always run
> against an older core version, whatever happened to be deployed,
> instead of reporting about the last version.
>
> Would it be reasonable to have the primary job
> (Infinispan-master-JDK6-tcp) deploy snapshots at each execution? I'd
> like it to deploy to jboss.org, but it might generate quite some load
> and would need us to give him permissions.
> I see there is an option "Deploy artifacts to my Private CloudBees
> Repository", not sure if we have such a thing, nor if the secondary
> module will find it from there.
>
> Cheers,
> Sanne
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
[hidden email]
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org




_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] build failures on jenkins

Galder Zamarreno
Hmmm, I don't see why that should be a problem. There're are ongoing builds at the moment, I'll update the config when they're done and we can see the effect on the Lucene build.

There're alternative ways to deal with this though. At the moment we do fork=none, so to enable TRACE, we need to do it a the Maven JVM level, so it's not really practical to have TRACE build do: '-pl core,lucene-directory'. However, the CloudBees guys have given me some tips on how to use fork=once and some log4j+maven magic to have selective, per project, TRACE within an entire build, without forcing everyone to have TRACE. So, if we end up implementing this, we could have this particular job build both core and lucene-directory and hence avoid this snapshot issue.

I need to compile the stuff I got from CloudBees and create a JIRA with it...

On Aug 2, 2011, at 4:50 PM, Manik Surtani wrote:

> Galder, any thoughts on this?
>
> On 2 Aug 2011, at 15:43, Sanne Grinovero wrote:
>
>> Hi,
>> it seems that the Infinispan-lucene-master task relies on deployed
>> snapshots of core, and since there aren't any for 5.1, it's failing.
>>
>> https://infinispan.ci.cloudbees.com/job/Infinispan-lucene-master-TRACE/73/changes
>>
>> So even if I deploy a snapshot, it means the tests are always run
>> against an older core version, whatever happened to be deployed,
>> instead of reporting about the last version.
>>
>> Would it be reasonable to have the primary job
>> (Infinispan-master-JDK6-tcp) deploy snapshots at each execution? I'd
>> like it to deploy to jboss.org, but it might generate quite some load
>> and would need us to give him permissions.
>> I see there is an option "Deploy artifacts to my Private CloudBees
>> Repository", not sure if we have such a thing, nor if the secondary
>> module will find it from there.
>>
>> Cheers,
>> Sanne
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> [hidden email]
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] build failures on jenkins

Galder Zamarreno
Here's the JIRA: https://issues.jboss.org/browse/ISPN-1298

On Aug 2, 2011, at 6:08 PM, Galder Zamarreño wrote:

> Hmmm, I don't see why that should be a problem. There're are ongoing builds at the moment, I'll update the config when they're done and we can see the effect on the Lucene build.
>
> There're alternative ways to deal with this though. At the moment we do fork=none, so to enable TRACE, we need to do it a the Maven JVM level, so it's not really practical to have TRACE build do: '-pl core,lucene-directory'. However, the CloudBees guys have given me some tips on how to use fork=once and some log4j+maven magic to have selective, per project, TRACE within an entire build, without forcing everyone to have TRACE. So, if we end up implementing this, we could have this particular job build both core and lucene-directory and hence avoid this snapshot issue.
>
> I need to compile the stuff I got from CloudBees and create a JIRA with it...
>
> On Aug 2, 2011, at 4:50 PM, Manik Surtani wrote:
>
>> Galder, any thoughts on this?
>>
>> On 2 Aug 2011, at 15:43, Sanne Grinovero wrote:
>>
>>> Hi,
>>> it seems that the Infinispan-lucene-master task relies on deployed
>>> snapshots of core, and since there aren't any for 5.1, it's failing.
>>>
>>> https://infinispan.ci.cloudbees.com/job/Infinispan-lucene-master-TRACE/73/changes
>>>
>>> So even if I deploy a snapshot, it means the tests are always run
>>> against an older core version, whatever happened to be deployed,
>>> instead of reporting about the last version.
>>>
>>> Would it be reasonable to have the primary job
>>> (Infinispan-master-JDK6-tcp) deploy snapshots at each execution? I'd
>>> like it to deploy to jboss.org, but it might generate quite some load
>>> and would need us to give him permissions.
>>> I see there is an option "Deploy artifacts to my Private CloudBees
>>> Repository", not sure if we have such a thing, nor if the secondary
>>> module will find it from there.
>>>
>>> Cheers,
>>> Sanne
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>> Manik Surtani
>> [hidden email]
>> twitter.com/maniksurtani
>>
>> Lead, Infinispan
>> http://www.infinispan.org
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] build failures on jenkins

Sanne Grinovero-3
2011/8/2 Galder Zamarreño <[hidden email]>:
> Here's the JIRA: https://issues.jboss.org/browse/ISPN-1298

Fine for me, but I don't understand why you had me remove the
log4j.xml file from the test resources in the module, aren't we
achieving the same effect?

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] build failures on jenkins

Galder Zamarreno

On Aug 2, 2011, at 6:33 PM, Sanne Grinovero wrote:

> 2011/8/2 Galder Zamarreño <[hidden email]>:
>> Here's the JIRA: https://issues.jboss.org/browse/ISPN-1298
>
> Fine for me, but I don't understand why you had me remove the
> log4j.xml file from the test resources in the module, aren't we
> achieving the same effect?

The problem of a file called 'log4j.xml' is that log4j automatically tries to find it and will use it everytime the testsuite is run.

I see logging as being something selective, something you sometimes enable but most of the time is disabled. So, what I wanted to avoid having files called 'log4j.xml' all over the place. Imagine the sort of problems that appear if you relied on a module that already defines a log4j.xml  (i.e. infinispan core tests - not that) and you had another 'log4j.xml' in the classpath, which one would be resolved automatically? Which one will log4j choose? You have no idea and based on past experience, it's a royal PITA figuring out why your log4j.xml changes are not having an effect.

It's because of problems like this that I'd prefer names like 'log4j-lucene.xml' or something like that, and you selectively enable when you need it via a profile...etc.

>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] build failures on jenkins

Sanne Grinovero-3
2011/8/3 Galder Zamarreño <[hidden email]>:

>
> On Aug 2, 2011, at 6:33 PM, Sanne Grinovero wrote:
>
>> 2011/8/2 Galder Zamarreño <[hidden email]>:
>>> Here's the JIRA: https://issues.jboss.org/browse/ISPN-1298
>>
>> Fine for me, but I don't understand why you had me remove the
>> log4j.xml file from the test resources in the module, aren't we
>> achieving the same effect?
>
> The problem of a file called 'log4j.xml' is that log4j automatically tries to find it and will use it everytime the testsuite is run.
>
> I see logging as being something selective, something you sometimes enable but most of the time is disabled. So, what I wanted to avoid having files called 'log4j.xml' all over the place. Imagine the sort of problems that appear if you relied on a module that already defines a log4j.xml  (i.e. infinispan core tests - not that) and you had another 'log4j.xml' in the classpath, which one would be resolved automatically? Which one will log4j choose? You have no idea and based on past experience, it's a royal PITA figuring out why your log4j.xml changes are not having an effect.
>
> It's because of problems like this that I'd prefer names like 'log4j-lucene.xml' or something like that, and you selectively enable when you need it via a profile...etc.

Right, makes sense. I thought this was an Eclipse users only problem,
since we usually don't include the test resources in the classpath of
other modules, but Eclipse would add them when opening multiple
modules, and all builds would include an eventual file from
Infinispan's testing suite.
I agree it's worth trying what you proposed on this JIRA, if it
doesn't work I can live with the multiple resources since Eclipse at
least seems to order them properly so I always get the right one
loaded.

Cheers,
Sanne

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev