Switch to DuckDuckGo Search
   December 14, 2009  
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >


NOTICE: This channel is no longer actively logged.

Toggle Join/Part | bottom
[17:00:53] *** echelog-1 has joined #hudson
[17:17:48] * kleini ist away (Going pumping...)
[17:18:12] *** Chuck_ has joined #hudson
[17:19:34] <Chuck_> Anyone here having experience with configuring hudson from other applications?
[17:20:05] *** nairb774 has quit IRC
[17:20:54] <Chuck_> We want to automatically create views (based on Regex) and add views to the 'my views' of the different users using another application (functionally analogous to creating jobs via xml-POST-api)
[17:21:15] <Chuck_> I didn't find anything about this
[17:21:47] *** Nacho_Man has joined #hudson
[17:21:47] *** giskard has joined #hudson
[17:21:47] *** sflanigan has joined #hudson
[17:21:47] *** Hill has joined #hudson
[17:23:28] <Chuck_> Is ANYONE here?????
[17:23:44] *** nairb774 has joined #hudson
[17:23:46] *** acarbs12 has quit IRC
[17:23:59] *** acarbs12 has joined #hudson
[17:25:12] *** Spencer_ has joined #hudson
[17:25:26] <Spencer_> Hi all
[17:34:19] *** Spencer_ has quit IRC
[17:35:18] *** vjuranek_ has quit IRC
[17:43:40] *** Chuck_ has quit IRC
[18:00:01] *** mindless has quit IRC
[18:00:54] *** mindless has joined #hudson
[18:00:54] *** ChanServ sets mode: +o mindless
[18:23:05] *** matt-wynne has joined #hudson
[18:23:37] *** hobodave has joined #hudson
[18:38:48] *** keshureddyp has quit IRC
[18:41:20] *** matt-wynne has quit IRC
[18:42:05] *** abayer has quit IRC
[18:46:26] *** keshureddyp has joined #hudson
[18:49:54] *** John__ has joined #hudson
[18:50:18] <John__> Hey guys, I'm looking for a way to group JUnit test results by module. I'm using the free-form style of project.
[18:50:20] <John__> Is this possible?
[18:57:56] *** Lewisham has joined #hudson
[18:57:57] *** ChanServ sets mode: +v Lewisham
[19:04:28] *** Lewisham has quit IRC
[19:08:50] *** Lewisham has joined #hudson
[19:08:50] *** ChanServ sets mode: +v Lewisham
[19:19:00] *** Lewisham has quit IRC
[19:21:21] *** DaveH has quit IRC
[19:28:18] *** matt-wynne has joined #hudson
[19:34:48] *** mindless has quit IRC
[19:36:01] *** mindless has joined #hudson
[19:36:02] *** ChanServ sets mode: +o mindless
[19:37:03] *** dvrzalik has quit IRC
[20:02:09] *** admc has joined #hudson
[20:13:22] *** macetw has joined #hudson
[20:13:35] *** nairb774 has joined #hudson
[20:15:36] *** abayer has joined #hudson
[20:15:37] *** ChanServ sets mode: +o abayer
[20:19:55] *** macetw has left #hudson
[20:20:36] *** matt-wynne has quit IRC
[20:25:34] *** John__ has quit IRC
[20:51:12] *** giskard has joined #hudson
[21:01:50] *** Hornswoggles has joined #hudson
[21:08:28] *** nairb774 has quit IRC
[21:09:04] *** nairb774 has joined #hudson
[21:10:09] *** tstclair has quit IRC
[21:13:20] *** mindless has quit IRC
[21:14:00] *** mindless has joined #hudson
[21:14:00] *** ChanServ sets mode: +o mindless
[21:14:52] *** whaley has joined #hudson
[21:15:13] *** tstclair has joined #hudson
[21:16:39] *** admc has quit IRC
[21:34:38] *** admc has joined #hudson
[21:43:43] <evilchili> philosophical question: is it wiser to consider critical path unit tests as part of the compilation loop, or as separate jobs?
[21:47:21] <mrooney> that is an interesting question!
[21:49:47] <kleini> i would say, if those critical path unit tests require other resources except source code I would separate them into another job
[21:50:15] <mrooney> I can see the point of considering the build broken if certain very critical acceptance tests fail
[21:50:26] <mrooney> such that it isn't even worth running the entire suite
[21:51:07] <evilchili> yeah i can see reasonable arguments either way
[21:54:26] <evilchili> we have separate engineering groups whose work depends on different critical paths
[21:54:41] <evilchili> so it's possible that a given unit test could fail, blocking one engineering group, but not another
[21:54:57] <evilchili> which implies a separate job so as to still have a 'successful' build available to one group vs another
[22:06:32] *** WilliamLeara has quit IRC
[22:06:34] *** WilliamLeara has joined #hudson
[22:07:02] <kleini> simply try a best guess solution and check if it fits the needs of your engineering groups
[22:07:36] <kleini> me too did some tries until I found the final good solution how to split up the jobs
[22:08:12] <kleini> the only thing I am missing is multiple SCMs in one job. I want to use CVS and URL SCM
[22:08:16] <kleini> not either of them
[22:08:42] <kleini> URL SCM for artifacts of previous job and CVS for getting the scripts for the current build job
[22:08:52] <kleini> hopefully this gets done sometimes in Hudson
[22:08:53] *** jieryn-w has quit IRC
[22:09:08] <kleini> CruiseControl already supports this
[22:18:46] *** jieryn-w has joined #hudson
[22:18:46] *** ChanServ sets mode: +v jieryn-w
[22:18:53] <evilchili> kleini — you mean just doing a checkout/update from two SCMs?
[22:19:04] <evilchili> i'm doing this now with two separate subversion repos
[22:19:33] * evilchili pokes the config screen
[22:19:50] <evilchili> ah. i see what you mean. you can have multiple URLs for a single SCM type
[22:20:35] <kleini> evilchili, but you can not combine URL and CVS SCM
[22:20:45] <evilchili> right
[22:21:03] <rpetti> It would be nice to be able to add SCMs
[22:24:15] <evilchili> do the post-build actions fire regardless of success/failure?
[22:27:25] <kleini> evilchili, the post-build actions are executed on a failure
[22:29:57] * rpetti ponders a meta-SCM plugin
[22:33:58] <evilchili> oh hrm. post-build actions will fail a build if they fail.
[22:34:37] <evilchili> i'd rather a distinction between the hudson job failing and the build failing. guess i'm not going to have that. :)
[22:35:09] <kleini> evilchili, then do not let the build fail but let it get unstable
[22:35:40] <kleini> failed unit tests do not fail the build be the complete job is marked as unstable
[22:36:45] <evilchili> kleini: yeah but that logic doesn't extend to all post-build actions. For example, failing to archive build artifacts
[22:37:32] <kleini> archiving build artifacts never failed for my jobs. maybe this is because I use wildcards
[22:37:40] <kleini> that may have zero matches
[22:37:45] <evilchili> ah indeed
[22:39:56] * kleini has to go home now
[22:40:16] * kleini ist away (Going pumping...)
[22:53:29] <evilchili> it would be nice if /fingerprintCheck didn't refer to a jar file specifically; it will confuse my poor engineers
[22:59:18] *** giskard has quit IRC
[22:59:26] *** whaley has quit IRC
[23:03:14] *** WilliamLeara has quit IRC
[23:03:30] *** WilliamLeara has joined #hudson
[23:05:02] <lifeless> kohsuke: hi
[23:06:16] <kohsuke> hi
[23:06:59] <lifeless> what are the costs of binary incompatibility ?
[23:08:00] <kohsuke> A typical scenario is that we'll hear from a lot of users that their plugins suddenly stopped working.
[23:08:45] <abayer> ...and we end up with 18 billion bug reports. =)
[23:08:52] <lifeless> can plugins express a minimum version ?
[23:09:47] <lifeless> the background here is that I think we can (incrementally) cleanup a bunch of security code and delete many subclasses of acegi things that were done because the old framework didn't understand passwordless environments
[23:09:53] <kohsuke> Yes, but we don't know which ones of the current plugins are rendered incompatible.
[23:10:10] <lifeless> kohsuke: well we can tell for all the ones in svn; how many are not in svn ?
[23:10:29] <kohsuke> we don't know for sure how many plugins are developed in house
[23:10:36] <lifeless> at a guess?
[23:10:49] <kohsuke> But last time when I looked at the usage statistics, there are about the same number of in-house plugins as we have in the public.
[23:11:16] <lifeless> and what if we sent a mail to the users list: 'in a month we'll apply X patch, if you have in house security plugins you need to do XYZ. Tell us if this patch gives you trouble and we'll delay landing it'
[23:11:50] <kohsuke> I'm sure it'll help, but I'm afraid the improvement is limited.
[23:11:52] <lifeless> I mean, I think it sucks that acegi/spring security didn't provide a binary compatible transition
[23:12:00] <kohsuke> Amen to that
[23:12:11] <kohsuke> AFAICT they renamed just because they wanted to put "Spring" in the name
[23:12:34] <lifeless> but I don't want to have to figure out all the bugs they did adding openid in the first place, and then how to do compatible changes to our whole stack
[23:12:54] <kohsuke> As for the passwordless thing, yes, the abstraction is awkward, but we know it can be made to work for passwordless environments
[23:13:15] <lifeless> we do, because we've hacked around it: their core supports it now.
[23:18:52] <lifeless> so look, its your call, but I'm doing this in personal time for personal itches; I've seen projects that take ownership of dependencies rather than upgrading, when upstream are still mostly sane - and it doesn't end well.
[23:19:16] <lifeless> I'm pretty sure I don't want to put effort into that path: mitigating the cost of ugprading - sure. Not upgrading -> ugh.
[23:20:01] <lifeless> At a minimum I think you should make some noise about their decision - or I may, though I'm nowhere near as well known in the java space as you guys ;)
[23:21:18] <kohsuke> In the past I don't think we really felt the need to keep up with Acegi Security
[23:21:37] <kohsuke> And so far I think the only tangible benefit for upgrading is the OpenID support.
[23:21:57] <kohsuke> I don't think that's good enough justification for our users for the pain this will incur.
[23:22:02] <kohsuke> So I feel like my hands are tied.
[23:22:36] <kohsuke> I appreciate that you are doing this
[23:22:39] <lifeless> the only benefit I've investigated is openid
[23:22:48] <lifeless> external user benefit, I mean
[23:23:19] <lifeless> I don't know if there are others, or not. Theres a bunch of configuration hoopla, but as far as I can tell its irrelevant to hudson as we dynamically set everything up anyway.
[23:23:31] <kohsuke> right.
[23:23:46] <kohsuke> From what I've read, it has a better integration with the rest of Spring, but that doesn't affect us.
[23:24:35] <lifeless> so, if I write stubs for the 6 or so classes that are used by svn-hosted plugins
[23:24:46] <lifeless> I think thats a pretty good chance it will cover most inhouse ones too
[23:25:02] <lifeless> we have about 150 references to acegi in plugins/**
[23:25:49] <lifeless> and I'm happy to do that - I see real value in simply using a slightly cleaner framework that is getting attention from other folk
[23:26:33] <kohsuke> You can just stub 6 classes and make existing plugins work without a binary change?
[23:26:37] *** abayer has quit IRC
[23:26:50] <kohsuke> If that's true, I'm all for it
[23:28:17] <lifeless> kohsuke: I'm willing to give it a go
[23:28:52] *** tstclair is now known as tstclair_bbl
[23:29:26] <kohsuke> But there's still a risk of this not quite working out as intended
[23:29:38] <kohsuke> Isn't it better use of our time to just use openid4java?
[23:29:46] <kohsuke> Your goal is to make OpenID work with Hudson, right?
[23:29:57] <kohsuke> Aren't we starting to shave a yak here?
[23:30:41] <kohsuke> I've used openid4java. It might not be the best library in the world, but it worked for me for http://openid.java.net/
[23:32:19] <lifeless> kohsuke: so someone has already written openid code for spring :P I am shaving a yak, but shaving the yak hopefully means I don't need to duplicate that code
[23:33:05] <lifeless> I have a plugin based on your ad one that adds openid, I just need to hook in the form changes so that the right callback is trigger, AFAICT
[23:36:41] <kohsuke> I feel bad because I feel like I'm letting you down or being too stubborn, but I still think the best course of action is to keep acegi-security and have OpenID support implemented via the standalone openid4java library
[23:37:12] <kohsuke> I feel so bad that I'm even willing to do some implementation work.
[23:38:00] <lifeless> I don't think you should feel bad
[23:38:47] <lifeless> compatability discussions are always tricky, in any project
[23:39:14] <lifeless> and hudson has an enviable selection of plugins, in no doubt partly because of the concern for compatability
[23:39:30] *** stigkj has joined #hudson
[23:39:34] *** stigkj has quit IRC
[23:39:36] *** stigkj has joined #hudson
[23:43:13] *** Hornswoggles has quit IRC
[23:45:53] *** Hornswoggles has joined #hudson
[23:51:12] *** giskard has joined #hudson
[23:52:12] <evilchili> is there any way to specify multiple artifact wildcards for a matrix build?
[23:52:53] <kohsuke> lifeless: I have to drop off to go to several meetings
[23:53:17] <kohsuke> I really appreciate all your work
[23:56:13] <lifeless> kohsuke: ciao
top

   December 14, 2009  
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >