Responding to my last post, Josh pointed out what should probably be obvious: It's likely a bad idea to bundle bundler. There's a potential for version conflicts.
For our second attempt, we're
As a second attempt, we're now cribbing from the continuous integration setup from the Rails project. So far, so good:
Our RAILS_ROOT/cruise_config.rb...
require 'fileutils'
Project.configure do |project|
project.build_command = 'sudo gem update --system && ruby lib/cruise/build.rb'
end
And, the referenced lib/cruise/build.rb (the important parts)...
#!/usr/bin/env ruby
require 'fileutils'
include FileUtils
def root_dir
@root_dir ||= File.expand_path(File.dirname(__FILE__) + '/../..')
end
def rake(*tasks)
tasks.each { |task| return false unless system("#{root_dir}/bin/rake", task, 'RAILS_ENV=test')}
end
build_results = {}
cd root_dir do
build_results[:bundle] = system 'gem bundle' # bundling here, rather than in a task (not in Rails context)
build_results[:spec] = rake 'cruise:spec'
end
failures = build_results.select { |key, value| value == false }
if failures.empty?
exit(0)
else
exit(-1)
end
Thanks go to
- Josh Susser for help via email
- John Pignata for suggesting we look at the Rails project
- Rails team for the reference scripts
More comments and suggestions are encouraged.
On a current project, we've just switched from GemInstaller to Bundler for managing our application's gems.
All in all, the transition was painless... in our development environments. Of course, in order to keep things on running smoothly on the continuous integration box, we amended our rake cruise:spec task to start by running sh "gem bundle".
So, wonderful! Any changes to our gem dependency list will picked up when cruise starts and made available for that "build"; there's no need to log in and make any manual updates. Right?
Not quite. We're using the disable_system_gems option and, in that case, Bundler (very intentionally) modifies your GEM_PATH such that only "vendor'd" gems are available to the application. Which of course means that Bundler itself, being "a gem to bundle gems", is unavailable when that sh "gem bundle" command is run.
Our solution: bundle Bundler, obviously! That's right, in our Bundler Gemfile we've included gem "bundler". Now, after a single manual execution of gem bundle to pick up the bundled Gem Bundler gem bundle (heh), any subsequent Gemfile changes (to gems other than Bundler) get picked up at the start of the build... and we're cruisin'
Have another solution? Please let us know in the comments.
Help
Why is upgrading to Ruby 1.8.7 so painful?
More specifically, a Pivot was wondering why there seem to be so many ways to install Ruby and Rubygems on a Mac. There are a lot of different places where gems end up being installed depending on which version of Ruby you have installed, and the specifics of how you installed it. The conversation turned into one about RVM and Yehuda Katz' Bundler, two technologies that appear destined to make it much easier to easily combine a version of Ruby with a set of gems under a particular project.
What is that technology that allows for more complex condition hashes in ActiveRecord?
This must be ActiveRecord::Extensions, which allows for an expanded syntax in the conditions hash of AR finders. A debate was had as to whether hashes and arrays could possibly comprise a reasonable DSL for complex query logic, but surprisingly, the final word on the subject was not reached during standup.
We are using
curlto talk to a Mongrel/Rack server that is running some specs. That server is emitting dots (just as any Rspec process would), but we cannot get those dots to show up in real-time on the client. The only way we've been able to force a flush is with a newline character, but that gives us an ugly vertical column of dots. Any suggested hacks for this?
The Bay Area Chef Meetup Group is meeting on 10/14 in Mountain View. If you're into Chef (and here at Pivotal we use it extensively), you might want to check it out.