2011-04-12 20 views
7

En el proyecto de carriles estoy trabajando en lo insertan apoyo a rspec, pepino y autotest con este Gemfile (parcial)Plataforma gemas específicas para autotest con bundler

gem 'rspec-rails' 
gem 'cucumber-rails' 
gem 'autotest-standalone' 
gem 'autotest-rails-pure' 
gem 'zentest-without-autotest' 

Sin embargo, a fin de ejecutar las pruebas con autotest i necesidad de ejecutar bundle exec autotest de lo contrario se produce un error con este mensaje

$ autotest 
loading autotest/cucumber_rails_rspec_rspec2 
Error loading Autotest style autotest/cucumber_rails_rspec_rspec2 (no such file to load -- autotest/cucumber_rails_rspec_rspec2). Aborting. 

Ahora estoy desarrollando en un Mac y me gustaría para permitir autotest-gruñido y autotest-fsevents joya, pero si inserto esas líneas en mi ~/.autotest

require 'autotest/growl' 
require 'autotest/fsevent' 

entonces necesito para insertar las gemas correspondientes en el Gemfile y todo funciona, pero se rompe se basa en mi servidor CI (que está en Linux)

¿Cómo resolver esto sin mantener un Gemfile diferente para locales y entornos de CI?

EDIT:

Por el momento he resuelto con estas líneas en Gemfile

if RUBY_PLATFORM.downcase.include?("darwin") # I'm on Mac 
    gem 'autotest-fsevent' 
    gem 'autotest-growl' 
end 

Funciona tanto a nivel local y en el servidor IC, no sé si es algo lío, por el momento parece funcionar sin problemas.

Cualquier forma más limpia de hacerlo es bienvenida.

Edit2:

que me pasa a soluciones grupos. Si bien el parche monopatch anterior funciona bastante bien tanto en desarrollo como para integración continua, le dará un error en la producción si utiliza las tareas de capistrano bundler para implementaciones o si usa la opción bundle install --deployment (que se recomienda en producción)

Al usar la línea if RUBY_PLATFORM.downcase.include?("darwin") obtendrá este error al implementar.

# bundle install --deployment --without development test 
You are trying to install in deployment mode after changing 
your Gemfile. Run `bundle install` elsewhere and add the 
updated Gemfile.lock to version control. 

You have deleted from the Gemfile: 
* autotest-fsevent 
* autotest-growl 

Así que mi solución definitiva a este problema es incluir gemas específicos de la plataforma en un grupo determinado, digamos OSX y, a continuación, en la producción y en el servidor IC excluye el uso de paquete.

Si utiliza Capistrano conseguir un despliegue de poner esto en su config.rb

set :bundle_without, [:development, :test, :osx] 
# capistrano bundler task 
require "bundler/capistrano" 

Respuesta

0

Es posible que desee utilizar grupos en su Gemfile, algo así como:

group :development do 
    gem "autotest-growl" 
    gem "autotest-fsevents" 
end

y en el servidor que utilice: $ bundle install --without development

+0

Utilizo [esta configuración] (https://github.com/fabn/rails-jenkins-template) en mi ci, y me gustaría mantenerlo simple, así que me gustaría mantener mis pasos en ci como simple como 'paquete de instalación; rake spec; rastrillar el pepino' – Fabio

+0

Hago muchas búsquedas para este problema y no hay solución en este momento. Así que voy a aceptar tu respuesta como correcta. – Fabio

0

Puede manejar esto mediante el aprovechamiento de los diferentes entornos (Gemfile pruebas, desarrollo, producción).

Su caja local puede ser desarrollada mientras que el servidor de CI es su entorno de "producción".

Con esto en mente, puede editar su Gemfile para usar las gemas apropiadas dependiendo del entorno.

Editar: Lo siento, creo que escaneé tu publicación demasiado rápido. Pero puede agregar su ~/.autotest a .gitignore para que no se incluya en su servidor de CI.

+0

El archivo '~/.autotest' no es un problema, porque está en mi directorio personal, no en la raíz del proyecto. El problema es que requiere dos gemas que no están enumeradas en Gemfile, por lo que en el contexto del paquete que requiere esas gemas se genera un error de carga. Me gustaría evitar el otro enfoque (administrar diferentes entornos en Gemfile) para evitar la duplicación de configuraciones en ellos. – Fabio

+0

Ok, entiendo tu problema mejor. ¿Pero estás diciendo que no te gusta la idea de tener diferentes grupos de "prueba, desarrollo, producción" en tu Gemfile? Porque eso es exactamente para lo que están esos grupos; configuraciones de diff para entornos diff. Además, el hecho es que su CI y su servidor de desarrollo son bastante diferentes (linux vs osx). En lugar de preocuparme por esto, creo que debería centrarse en crear una forma reproducible de configurar su CI correctamente. Y puede hacer eso escribiendo su propia tarea de rake. – Dty

+0

Estoy de acuerdo con lo que dices, lo único que me gustaría evitar es poner las gemas dependientes de la plataforma (autotest-growl) en un entorno común (es decir, desarrollo), porque si necesito ejecutar la aplicación en una puesta en escena servidor con entorno de desarrollo (para mostrar una demostración o una prueba de concepto) no funcionará en Linux. – Fabio

Cuestiones relacionadas