FW: [projectblacklight/blacklight] f72090: cleanup test.sh script

[Chris Beer]

Hi all,

I just did some cleanup on the test.sh script and added two new features:

- the ability to specify (in an environment variable) what version(/version pattern) of Rails to use, e.g.:

$ RAILS_VERSION=3.1.3 test_support/bin/test.sh
$ RAILS_VERSION="~> 3.2" test_support/bin/test.sh

The default is to use the latest 3.2 version.

- the ability to specify the URL to download blacklight jetty (allow, e.g. , tests for different versions of solr)

$ JETTY_URL="http://.../v1.4" test_support/bin/test.sh

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.

Thanks,
Chris

> Commit: f72090be49fefa8f883fa69f8a3caf6f2ed50d6c
> https://github.com/projectblacklight/blacklight/commit/f72090be49fefa8f883fa69f8a3caf6f2ed50d6c
> Author: Chris Beer <chris...@wgbh.org>
> Date: 2012-01-23 (Mon, 23 Jan 2012)
>
> Changed paths:
> M test_support/bin/test.sh
>
> Log Message:
> -----------
> cleanup test.sh script
>
>
> Compare: https://github.com/projectblacklight/blacklight/compare/e4593cb...f72090b

[Chris Beer]

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.

The 4 Blacklight builds are currently:

- Ruby 1.9.3 + Rails 3.2
- Ruby 1.8.7 + Rails 3.2
- JRuby 1.6.2 + Rails 3.1 (JRuby + Rails 3.2 is broken on Hudson)
- Ruby 1.9.3 + Rails 3.1

Thanks,
Chris

> --
> You received this message because you are subscribed to the Google Groups "Blacklight Development" group.
> To post to this group, send email to blacklight-...@googlegroups.com.
> To unsubscribe from this group, send email to blacklight-develo...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/blacklight-development?hl=en.
>

[Jonathan Rochkind]

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

[Chris Beer]

I filed a ticket about this during the committers call when it came up:
http://jira.projectblacklight.org/jira/browse/CODEBASE-388

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.

[Chris Beer]

Hi all,

I am playing around with the Hudson multi-configuration project:

http://hudson.projectblacklight.org/hudson/view/Blacklight/job/Blacklight_multiconfig/

as a replacement for multiple projects for different platforms:
http://hudson.projectblacklight.org/hudson/view/Blacklight/

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?

Thanks,
Chris

[Chris Beer]

I'd like to add some hudson topics for the next call:

- Multiconfig (http://hudson.projectblacklight.org/hudson/job/Blacklight_multiconfig/)

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

[Jonathan Rochkind]

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-...@googlegroups.com [blacklight-...@googlegroups.com] on behalf of Chris Beer [chris...@wgbh.org]
Sent: Wednesday, February 08, 2012 5:13 PM
To: blacklight-...@googlegroups.com
Subject: Re: [Blacklight-development] Blacklight Hudson tweaks