https://jira.codehaus.org/browse/HAUS-2316 and fixed
On Tue, 06 Aug 2013 23:27:34 +0200, Baptiste MATHUS <[email protected]> wrote:
Hi all, For the record, I just played a bit with the extra-enforcer-rules bambooconfiguration. I manually scheduled a build but this should still take sometime before it begins since there's only two agents and one seems stuck. See https://bamboo-ci.codehaus.org/build/admin/edit/editBuildTasks.action?buildKey=MOJO-MEXTRAENFORCERRULES-JOB1 for details. For those interested, I added two executions of "mvn clean verify -DenforcerPluginVersion=1.3.1" with m221 and m3. I might have added more combinations, but it's actually a bit cumbersome to configure many "axis"(IIUC, you actually have to add more executions and just configure each oneseparately. Matrix builds, I miss you here ;-)).Btw, Robert, as you talk about it, I think that we should actually ask form3.1 installation isn't it? Or do you think we better wait for m3.1.1? Cheers 2013/7/31 Robert Scholte <[email protected]>Hi Baptiste, not sure why you think that we only build with M2.2.1, see https://bamboo-ci.codehaus.**org/build/admin/edit/**editBuildTasks.action? **buildKey=MOJO-MAPPASM-JOB1<https://bamboo-ci.codehaus.org/build/admin/edit/editBuildTasks.action?buildKey=MOJO-MAPPASM-JOB1>This is probably a good example of a lot of combinations of JDKs and Mavenversions, both M2 and M3. Ben has installed specific versions of Maven for me in he past, so it shouldn't be too hard to get M3.1 here as well.I recently noticed that the aggregator has been disabled because it claims a lot of diskspace. This is probably caused by local repo's per plugin for the ITs, so we need think of a way to clean it up afterwards. With Jenkinswe will have the same problem. Yes, there's one important downside with bamboo infrastructure: IIRC due to the agents-setup you can't access the workspace. So you have to do it with the logging or ask support@ to send you a zip. I'm only interested in Jenkins if it stays within the Codehaus infrastructure, i.e. controlled through xircles.If you need help with some specific plugins to run with Bamboo, just PM mewith your concrete ideas/questions. RobertOn Wed, 31 Jul 2013 14:10:25 +0200, Baptiste MATHUS <[email protected]> wrote:Hi all,I was thinking about the fact that IIUC we currently build in Bamboo onlywith one version of Maven (2.2.1). Sure, YMMV, but I remember digging a bitto see how to change it and I found it was a bit complicated and/or slow(granted, I don't know bamboo). I wonder if using Jenkins it wouln't be a little simpler to handle multi-aspects testing (*matrix builds*, I'm looking at you).We could in fact come up with a quite standard matrix build template for any plugin @MOJO to test for example different maven versions, different JDK, or even different parameters values (thinking of extra-enforcer-rulesfor examples, where we could test against the differen m-e-p versions quite easily using a matrix build).Maybe we could ask CloudBees to see if they can provide the correspondingrequired infra? Or ask for Jenkins@MOJO? WDYT? Thanks2013/3/22 Stephen Connolly <stephen.alan.connolly@gmail.**com<[email protected]>> There are things we can do with the RBAC plugin and folders that mightsolve those issues... but I need to chat with Ben as to how to delegateauth for a mojo project jenkins to xircles... On 22 March 2013 12:17, Mirko Friedenhagen <[email protected]>** wrote: Hello,I would like Jenkins better for codehaus as well (I hope I may reuse the account data from codehaus, jenkins-on-cloudbees e.g. would like to getinsight into public *and* private repositories on github, which makes it a no-go for me). Regards Mirko -- Sent from my mobile On Mar 21, 2013 10:08 AM, "Stephen Connolly" < stephen.alan.connolly@gmail.**com <[email protected]>> wrote:Well not suggesting *codehaus* abandon it. Just that we set up a JaaSfor the mojo project On Thursday, 21 March 2013, Baptiste MATHUS wrote:Sure, I personnally know Jenkins a lot better and sure would be morecomfortable with it.But I also like JIRA and don't know if atlassian would be happy withus ditching bamboo in favor of Jenkins. Cheers2013/3/20 Stephen Connolly <stephen.alan.connolly@gmail.**com<[email protected]>>Do we want a Jenkins at CloudBees? Might be easier for people to grok?On Tuesday, 19 March 2013, Robert Scholte wrote: Let me go through all the jobs. It looks to me something has changed, because I'm pretty sure Iconfigured notifications for failed builds and first successful to all committers (users who have committed to the build) for every mojo job.No real need to keep checking Bamboo as long as its green ;) Robert On Mon, 18 Mar 2013 22:57:52 +0100, Baptiste MATHUS < [email protected]> wrote:FYI, I just committed the corresponding fix/evolution. CI is now backtogreen (thanks Mirko for noticing it, I'll watch it better next time).I'm gonna launch the 3rd try :-). Thanks 2013/3/17 Arnaud Héritier <[email protected]> I'm in favor to have just a warning. It's enoughOn Sun, Mar 17, 2013 at 9:25 PM, Baptiste MATHUS <[email protected]>wrote: Yup, I was just copying the code ;-). Thanks.Btw, I'm gonna just display a warning. But if you feel we should failthe build, just let me know. I feel this might be counter-productive to fail the build for that. People might in fact allow running 2.x and 3.x versions of maven on thesame build, and failing here even if there's actually no cycle mightmake them just remove that rule (banCircularDependencies). 2013/3/17 Arnaud Héritier <[email protected]> The RequireMavenVersion Rule may help ? https://svn.apache.org/repos/****asf/maven/enforcer/trunk/**<https://svn.apache.org/repos/**asf/maven/enforcer/trunk/**> enforcer-rules/src/main/java/****org/apache/maven/plugins/** enforcer/RequireMavenVersion.****java<https://svn.apache.org/** repos/asf/maven/enforcer/**trunk/enforcer-rules/src/main/** java/org/apache/maven/plugins/**enforcer/RequireMavenVersion.**java<https://svn.apache.org/repos/asf/maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireMavenVersion.java> >On Sun, Mar 17, 2013 at 9:12 PM, Baptiste MATHUS <[email protected]>wrote: OK, I'll go that way.If anyone sees this message just now and knows *the right way to checkthe maven version in use in an enforcer rule, I'm interested.* Thanks 2013/3/17 Mirko Friedenhagen <[email protected]>I would prefer solution 1 and just document this behaviour (and setthe Bamboo job to Maven 3). Otherwise you will have this switch in code,you should introduce two ITs, one with a failure status on Maven 3 andone with a skipped message on Maven 2. Honestly, new feature, new Maven should be no problem. Regards Mirko -- Sent from my mobile On Mar 16, 2013 10:42 PM, "Baptiste MATHUS" <[email protected]> wrote: In the circular IT, there's a circular dependency (now that's some news!). But M2 just ignores it silently, not M3. I think we hit http://jira.codehaus.org/****browse/MNG-1944<http://jira.codehaus.org/**browse/MNG-1944> <http://jira.**codehaus.org/browse/MNG-1944<http://jira.codehaus.org/browse/MNG-1944> > So, here we have an choice: either we1) explicitly state (and check during execution?) that this rule canonly be useful with M3 or 2) we simply remove it. I'd be for solution 1. I feel it's a valuable addition and as itworks for the latest and greatest Maven, this makes sense to keep it.WDYT? Cheers 2013/3/15 Baptiste MATHUS <[email protected]> No problem, and true for the IT.I've copied the demo from the website and forgot to update that part.I can re-roll a release. Now-- Sent from my phone -- Baptiste <Batmat> MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;!-- Using Opera's revolutionary email client: http://www.opera.com/mail/ ------------------------------**------------------------------**--------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/**manage_email<http://xircles.codehaus.org/manage_email>
-- Using Opera's revolutionary email client: http://www.opera.com/mail/ --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
