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.
This week we moved our gems over to GemCutter. It's very easy to claim the gems that were automatically synced over from RubyForge, but if you have gems on GitHub it takes a little more work. We had several gems to move over, some of which had quite a few versions we wanted to preserve. You can't just push the .gem files over because GitHub built the gem namespaced with your username (e.g. "pivotal-apdex"). So Sam and I built a little script to pull down the gems from gems.github.com, fix the name in the spec, repack, and push up to GemCutter.
You can get the hubcut script at http://gist.github.com/220908
Interesting Things
- IE doesn't allow you to change the type of an input. If you create an input with createElement, IE will not allow you to change that element to a button. This was discovered when a project's javascript dom builder code was modified to generate inputs of type=button rather than type=submit. The cross-browser solution was to create some other temporary dom element such as a div and then set the innerHtml of that element to a type=button input, then extract that child element and return it in the builder call. Yeah!
Ask for Help
"What's the best way to get gems for forked repos?"
There was quite a discussion on this. The specific issue is that the team is trying to use Compass (Chris Eppstein gave a talk on Compass at Pivotal on 3/18-look for the future video on our Talks Page.) For the moment, since compass depends on the edge version of sass you must first manually install sass before installing the compass gem.
- One suggestion was to submit a fix for the gem. This is not a good solution in this case since the new version of sass/haml is expected to be released soon, fixing compass and simplifying its installation.
- Pivotal will likely host its own internal gem server at some point to deal with issues like this.
- The Has My Gem Built Yet? service might be useful in some situations, but not for this specific problem.
Interesting Things
- In response to our ask for help, Ray Baxter answered us in code with a script called Firefoxen. "It’s a script to automatically configure multiple installations of Firefox so that they open with different profiles." You can grab Firefoxen on GitHub. Thanks Ray!
IE7 sends odd
Acceptheaders (*.*instead of an explicittext/html) which can cause undesired behavior in Rails. Someone suggested manually setting the format in abefore_filter:params[:format] ||= 'text/html'
This was discouraged because it can cause problems elsewhere. A better solution was to put the html format at the top of any `respond_to` blocks:def show respond_to.html # run by default when type cannot be determined respond_to.js end
The Ruby MySQL Gem version 2.7 leaks memory for very large queries. The solution is to remove the 2.7 gem and manually install version 2.8 from source. This library is no longer a gem and must be installed from the mysql-ruby-2.8 tarball.
Ask for Help
"As a followup to Firefox SSL certificate problems..."
It turns out that our server running nginx had an old version of OpenSSL installed. Upgrading OpenSSL solved the problem.