Related, I've pinned the JRuby hudson build to Rails 3.1 until we can figure out what (upstream project) is responsible for the CI failures with Rails 3.2.
> Related, I've pinned the JRuby hudson build to Rails 3.1 until we can figure out what (upstream project) is responsible for the CI failures with Rails 3.2.
> -- > You received this message because you are subscribed to the Google Groups "Blacklight Development" group. > To post to this group, send email to blacklight-development@googlegroups.com. > To unsubscribe from this group, send email to blacklight-development+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/blacklight-development?hl=en.
I am uncomfortable that we aren't testing jruby and rails 3.2, even though we say we support it. Even if the current CI failure is not our fault and doens't actually prevent someone from running jruby+3.2, if we're not testing it, it's possible we (who don't actually develop on jruby mostly) will later accidentally introduce a change that really DOES cause a problem with jruby and 3.2, and never know about it, cause our CI won't tell us.
Testing on MRI+3.2 and jruby+3.1 does ameliorate it somewhat, but still.
So if I understand right, we (cbeer) is thinking the hudson failure on jruby+3.2 is due to something not our fault that doesn't _actually_ keep someone from using jruby, BL, and rails 3.2. But we don't understand exactly what's going on. And we're hoping that someone upstream will fix it themselves soon.
That seems okay for a limited period. Should we maybe create a JIRA ticket reminding us to check on this again and restore jruby+3.2 testing, committing to a time period by which we'll do that? Maybe 60 days? Temporarily running like this seems okay, but the longer we go without CI on jruby+3.2, the more likely we'll accidentally introduce problems and the more potential problems we'll have to fix when we finally get to it.
>> Related, I've pinned the JRuby hudson build to Rails 3.1 until we can figure out what (upstream project) is responsible for the CI failures with Rails 3.2.
The JRuby + Rails 3.2 error occurs in the Rails application phase of the test, so it actually does prevent someone from running jruby + 3.2. Presumably we're not the only ones running into this problem either (and I've seen some suggestion that 1.9 mode fixes it -- which it does, but introduces a separate problem). I've also had no luck recreating the specific hudson error locally, but have other issues in the same phase.
On Jan 25, 2012, at 11:02 AM, Jonathan Rochkind wrote:
> I am uncomfortable that we aren't testing jruby and rails 3.2, even > though we say we support it. Even if the current CI failure is not our > fault and doens't actually prevent someone from running jruby+3.2, if > we're not testing it, it's possible we (who don't actually develop on > jruby mostly) will later accidentally introduce a change that really > DOES cause a problem with jruby and 3.2, and never know about it, cause > our CI won't tell us.
> Testing on MRI+3.2 and jruby+3.1 does ameliorate it somewhat, but still.
> So if I understand right, we (cbeer) is thinking the hudson failure on > jruby+3.2 is due to something not our fault that doesn't _actually_ keep > someone from using jruby, BL, and rails 3.2. But we don't understand > exactly what's going on. And we're hoping that someone upstream will fix > it themselves soon.
> That seems okay for a limited period. Should we maybe create a JIRA > ticket reminding us to check on this again and restore jruby+3.2 > testing, committing to a time period by which we'll do that? Maybe 60 > days? Temporarily running like this seems okay, but the longer we go > without CI on jruby+3.2, the more likely we'll accidentally introduce > problems and the more potential problems we'll have to fix when we > finally get to it.
> Jonathan
> On 1/25/2012 10:47 AM, Chris Beer wrote: >> I've updated the main Blacklight Hudson build to use ruby 1.9.3 (was 1.9.2) and Rails 3.2, and added a ruby 1.9.3 + rails 3.1 build as well.
>>> Related, I've pinned the JRuby hudson build to Rails 3.1 until we can figure out what (upstream project) is responsible for the CI failures with Rails 3.2.
> -- > You received this message because you are subscribed to the Google Groups "Blacklight Development" group. > To post to this group, send email to blacklight-development@googlegroups.com. > To unsubscribe from this group, send email to blacklight-development+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/blacklight-development?hl=en.
I'm not really convinced one approach is necessarily better than the other. The current approach has some configuration duplication, but the new approach adds another layer of indirection into the builds. Does anyone else have thoughts or preferences?
> The JRuby + Rails 3.2 error occurs in the Rails application phase of the test, so it actually does prevent someone from running jruby + 3.2. Presumably we're not the only ones running into this problem either (and I've seen some suggestion that 1.9 mode fixes it -- which it does, but introduces a separate problem). I've also had no luck recreating the specific hudson error locally, but have other issues in the same phase.
> On Jan 25, 2012, at 11:02 AM, Jonathan Rochkind wrote:
>> Cool, thanks cbeer.
>> I am uncomfortable that we aren't testing jruby and rails 3.2, even >> though we say we support it. Even if the current CI failure is not our >> fault and doens't actually prevent someone from running jruby+3.2, if >> we're not testing it, it's possible we (who don't actually develop on >> jruby mostly) will later accidentally introduce a change that really >> DOES cause a problem with jruby and 3.2, and never know about it, cause >> our CI won't tell us.
>> Testing on MRI+3.2 and jruby+3.1 does ameliorate it somewhat, but still.
>> So if I understand right, we (cbeer) is thinking the hudson failure on >> jruby+3.2 is due to something not our fault that doesn't _actually_ keep >> someone from using jruby, BL, and rails 3.2. But we don't understand >> exactly what's going on. And we're hoping that someone upstream will fix >> it themselves soon.
>> That seems okay for a limited period. Should we maybe create a JIRA >> ticket reminding us to check on this again and restore jruby+3.2 >> testing, committing to a time period by which we'll do that? Maybe 60 >> days? Temporarily running like this seems okay, but the longer we go >> without CI on jruby+3.2, the more likely we'll accidentally introduce >> problems and the more potential problems we'll have to fix when we >> finally get to it.
>> Jonathan
>> On 1/25/2012 10:47 AM, Chris Beer wrote: >>> I've updated the main Blacklight Hudson build to use ruby 1.9.3 (was 1.9.2) and Rails 3.2, and added a ruby 1.9.3 + rails 3.1 build as well.
>>>> Related, I've pinned the JRuby hudson build to Rails 3.1 until we can figure out what (upstream project) is responsible for the CI failures with Rails 3.2.
>> -- >> You received this message because you are subscribed to the Google Groups "Blacklight Development" group. >> To post to this group, send email to blacklight-development@googlegroups.com. >> To unsubscribe from this group, send email to blacklight-development+unsubscribe@googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/blacklight-development?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "Blacklight Development" group. > To post to this group, send email to blacklight-development@googlegroups.com. > To unsubscribe from this group, send email to blacklight-development+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/blacklight-development?hl=en.
I've been poking at the hudson multiple configuration builds for the last couple weeks, and I'm in favor of switching the Blacklight builds to the multiconfig build. I thought it was easier to maintain and add new configurations to, at least.
- Blacklight plugins under Hudson
I volunteered to get the official Blacklight plugins running under Hudson and have hit a couple trouble spots that I'm hoping to get help with.
Chris
On Jan 26, 2012, at 12:54 PM, Chris Beer wrote:
Hi all,
I am playing around with the Hudson multi-configuration project:
I'm not really convinced one approach is necessarily better than the other. The current approach has some configuration duplication, but the new approach adds another layer of indirection into the builds. Does anyone else have thoughts or preferences?
The JRuby + Rails 3.2 error occurs in the Rails application phase of the test, so it actually does prevent someone from running jruby + 3.2. Presumably we're not the only ones running into this problem either (and I've seen some suggestion that 1.9 mode fixes it -- which it does, but introduces a separate problem). I've also had no luck recreating the specific hudson error locally, but have other issues in the same phase.
On Jan 25, 2012, at 11:02 AM, Jonathan Rochkind wrote:
Cool, thanks cbeer.
I am uncomfortable that we aren't testing jruby and rails 3.2, even though we say we support it. Even if the current CI failure is not our fault and doens't actually prevent someone from running jruby+3.2, if we're not testing it, it's possible we (who don't actually develop on jruby mostly) will later accidentally introduce a change that really DOES cause a problem with jruby and 3.2, and never know about it, cause our CI won't tell us.
Testing on MRI+3.2 and jruby+3.1 does ameliorate it somewhat, but still.
So if I understand right, we (cbeer) is thinking the hudson failure on jruby+3.2 is due to something not our fault that doesn't _actually_ keep someone from using jruby, BL, and rails 3.2. But we don't understand exactly what's going on. And we're hoping that someone upstream will fix it themselves soon.
That seems okay for a limited period. Should we maybe create a JIRA ticket reminding us to check on this again and restore jruby+3.2 testing, committing to a time period by which we'll do that? Maybe 60 days? Temporarily running like this seems okay, but the longer we go without CI on jruby+3.2, the more likely we'll accidentally introduce problems and the more potential problems we'll have to fix when we finally get to it.
Jonathan
On 1/25/2012 10:47 AM, Chris Beer wrote: I've updated the main Blacklight Hudson build to use ruby 1.9.3 (was 1.9.2) and Rails 3.2, and added a ruby 1.9.3 + rails 3.1 build as well.
Related, I've pinned the JRuby hudson build to Rails 3.1 until we can figure out what (upstream project) is responsible for the CI failures with Rails 3.2.
-- You received this message because you are subscribed to the Google Groups "Blacklight Development" group. To post to this group, send email to blacklight-development@googlegroups.com. To unsubscribe from this group, send email to blacklight-development+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/blacklight-development?hl=en.
-- You received this message because you are subscribed to the Google Groups "Blacklight Development" group. To post to this group, send email to blacklight-development@googlegroups.com. To unsubscribe from this group, send email to blacklight-development+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/blacklight-development?hl=en.
-- You received this message because you are subscribed to the Google Groups "Blacklight Development" group. To post to this group, send email to blacklight-development@googlegroups.com. To unsubscribe from this group, send email to blacklight-development+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/blacklight-development?hl=en.
I'll war! Y'all now that I won't be at the call Monday-- I'll be on a plane back from the west coast, staying the weekend plus.
But I'm fine with chris doing whatever he thinks best with Hudson ________________________________________ From: blacklight-development@googlegroups.com [blacklight-development@googlegroups.com] on behalf of Chris Beer [chris_b...@wgbh.org] Sent: Wednesday, February 08, 2012 5:13 PM To: blacklight-development@googlegroups.com Subject: Re: [Blacklight-development] Blacklight Hudson tweaks
I'd like to add some hudson topics for the next call:
I've been poking at the hudson multiple configuration builds for the last couple weeks, and I'm in favor of switching the Blacklight builds to the multiconfig build. I thought it was easier to maintain and add new configurations to, at least.
- Blacklight plugins under Hudson
I volunteered to get the official Blacklight plugins running under Hudson and have hit a couple trouble spots that I'm hoping to get help with.
Chris
On Jan 26, 2012, at 12:54 PM, Chris Beer wrote:
Hi all,
I am playing around with the Hudson multi-configuration project:
I'm not really convinced one approach is necessarily better than the other. The current approach has some configuration duplication, but the new approach adds another layer of indirection into the builds. Does anyone else have thoughts or preferences?
The JRuby + Rails 3.2 error occurs in the Rails application phase of the test, so it actually does prevent someone from running jruby + 3.2. Presumably we're not the only ones running into this problem either (and I've seen some suggestion that 1.9 mode fixes it -- which it does, but introduces a separate problem). I've also had no luck recreating the specific hudson error locally, but have other issues in the same phase.
On Jan 25, 2012, at 11:02 AM, Jonathan Rochkind wrote:
Cool, thanks cbeer.
I am uncomfortable that we aren't testing jruby and rails 3.2, even though we say we support it. Even if the current CI failure is not our fault and doens't actually prevent someone from running jruby+3.2, if we're not testing it, it's possible we (who don't actually develop on jruby mostly) will later accidentally introduce a change that really DOES cause a problem with jruby and 3.2, and never know about it, cause our CI won't tell us.
Testing on MRI+3.2 and jruby+3.1 does ameliorate it somewhat, but still.
So if I understand right, we (cbeer) is thinking the hudson failure on jruby+3.2 is due to something not our fault that doesn't _actually_ keep someone from using jruby, BL, and rails 3.2. But we don't understand exactly what's going on. And we're hoping that someone upstream will fix it themselves soon.
That seems okay for a limited period. Should we maybe create a JIRA ticket reminding us to check on this again and restore jruby+3.2 testing, committing to a time period by which we'll do that? Maybe 60 days? Temporarily running like this seems okay, but the longer we go without CI on jruby+3.2, the more likely we'll accidentally introduce problems and the more potential problems we'll have to fix when we finally get to it.
Jonathan
On 1/25/2012 10:47 AM, Chris Beer wrote: I've updated the main Blacklight Hudson build to use ruby 1.9.3 (was 1.9.2) and Rails 3.2, and added a ruby 1.9.3 + rails 3.1 build as well.
Related, I've pinned the JRuby hudson build to Rails 3.1 until we can figure out what (upstream project) is responsible for the CI failures with Rails 3.2.
-- You received this message because you are subscribed to the Google Groups "Blacklight Development" group. To post to this group, send email to blacklight-development@googlegroups.com. To unsubscribe from this group, send email to blacklight-development+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/blacklight-development?hl=en.
-- You received this message because you are subscribed to the Google Groups "Blacklight Development" group. To post to this group, send email to blacklight-development@googlegroups.com. To unsubscribe from this group, send email to blacklight-development+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/blacklight-development?hl=en.
-- You received this message because you are subscribed to the Google Groups "Blacklight Development" group. To post to this group, send email to blacklight-development@googlegroups.com. To unsubscribe from this group, send email to blacklight-development+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/blacklight-development?hl=en.
-- You received this message because you are subscribed to the Google Groups "Blacklight Development" group. To post to this group, send email to blacklight-development@googlegroups.com. To unsubscribe from this group, send email to blacklight-development+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/blacklight-development?hl=en.
