2012-04-18 13 views
5

Tengo algunos problemas con los activos en producción: datos faltantes, material compilado en los archivos incorrectos (javascript para "/ admin" compilado en el código de interfaz, etc.). La mayoría de los activos provienen de motores. Quiero depurar y optimizar esto.Hacer que la canalización de activos actúe como producción en desarrollo

Por eso, tienen que precompilar, servir y fallar en mi entorno de desarrollo al igual que se hace en la producción .

he añadido algunas líneas a mi config/development.rb:

config.serve_static_assets = true 
    config.assets.precompile += %w(store/all.js store/all.css admin/all.js admin/all.css) # @TODO: clean up, and optimize. 
    config.assets.compile = false 

La ejecución de este con rake RAILS_GROUPS=assets RAILS_ENV=development assets:precompile me da todos los activos y la manifest.yml en public/.

Pero entonces el servidor falla:

Sprockets::Helpers::RailsHelper::AssetPaths::AssetNotPrecompiledError in Spree/home#index 

Showing /xxxx/app/views/spree/shared/_head.html.erb where line #13 raised: 

favicon.ico isn't precompiled 

favicon.ico no se precompila. ¡Pero es! Está allí, en el directorio público, en manifest.yml, y puedo buscarlo con el navegador (o wget): http://localhost:3000/assets/favicon.ico.

NOTA Favicon es simplemente el primer recurso llamado. Si elimino el favicon, el problema simplemente emerge con el siguiente activo, que es "all.js" o, cuando se elimina, "all.css", y así sucesivamente. Puedo quitarlo hasta "footer_bg.png", y luego fallará allí. De nuevo: el problema no es el favicon, sino el hecho de que el entorno de desarrollo no ve en absoluto los activos precompilados.

¿Qué más se necesita para conseguir el desarrollo tubería activo similar a la producción ?

EDITAR: explicación más explícita de que el favicon no es el problema, simplemente un síntoma.

+0

¿Cuál es su pila de entorno de producción? Servidor único/Servidor múltiple, Apache/Nginx, Heroku? ¿Estás desplegando usando capistrano y usando la receta capistrano? ¿Estás usando config.serve_static_assets = true en producción? ¿Has intentado manejar serve_static_assets a través de apache/nginx en lugar de dentro de Rails como recomienda Rails? – John

+0

Mi pila de producción es prácticamente una caja negra de pasajeros. Es un sitio 5 vhost. No estoy implementando con capistrano, pero con un gancho git-push && post-commit (también conocido como git-deploy). 'config.serve_static_assets = true' está deshabilitado. He intentado servir activos a través de Apache, sí. Resuelve poco. Como el problema que trato de resolver aquí, mi entorno ** de desarrollo ** no está sirviendo a mis activos como en la producción. – berkes

Respuesta

2

que terminó la instalación de un Apache, pasajero en localhost para solucionar problemas.

Apache (probablemente podría ser cualquier servidor de pasajeros) debido a la prestación de activos estáticos. Además, en localhost puedo subir la verbosidad de apache en sus registros muy alto, ofreciéndome suficiente información de depuración.

Pasajero para emular la versión de rubí y la carga de gemas tanto como sea posible en la producción.

Correr en webrick es simplemente demasiado diferente, incluso emulando lo más cerca posible, resultó ser muy diferente de una pila de producción; por eso no pude reproducir los problemas de producción allí,

Disparar toda la pila como si fuera producción me permitió solucionarlo.Lo que me llevó a concluir que varios problemas estaban causando los problemas de los activos: los activos de gemas no se recogen; un problema de permiso (recursos compilados no leíbles por www-data) y algunos activos que no se compilan correctamente.

0

creo que es posible que desee dejar favicon.ico en public ...

alzabo0:~ $ rails --version 
Rails 3.2.3 
alzabo0:~ $ rails new ojoijoijo 
[...] 
     create public/404.html 
     create public/422.html 
     create public/500.html 
     create public/favicon.ico 
     create public/index.html 
     create public/robots.txt 
[...] 
+0

Quizás. Pero eso no viene al caso. El problema no es favicon.ico, el problema es que mi entorno de desarrollo no reconocerá los activos compilados, como yo quiero. Y dado que elegí ejecutar favicon a través de la cartera de activos (historia larga), es el primer archivo que se incluye y simplemente es un ejemplo de dónde se estrangula la cartera de activos. Si muevo el favicon fuera de la tubería, como sugiere, la tubería de activos se ahogará unas líneas más abajo, en algún archivo css o js. – berkes

0

Sólo una conjetura, pero trate de añadir a su lista de precompilación:

config.assets.precompile += %w(store/all.js store/all.css admin/all.js admin/all.css favicon.ico) 
+0

Eso funciona de hecho. Lo extraño, es que en la producción esto no es necesario. Y dado que esta línea es una de las principales cosas que quiero limpiar, corregir y optimizar, esta es exactamente la parte que debería ser "igual que en la producción". – berkes

+0

extraño de hecho. tal vez en la producción, si "rastrillas los activos: limpios" ¿de repente tampoco funcionará allí? ¿Cómo hace referencia a favicon.ico en su plantilla de vista? Personalmente, no uso ayudantes para generar el enlace favicon.ico. ¿Estás usando favicon_link_tag? Es una cosa tan extraña, tal vez dejarlo en desarrollo por ahora y pasar a la parte interesante? – pduey

+0

Tenga en cuenta que favicon * no es el problema *. El problema es que mi entorno de desarrollo no reconocerá los activos cuando se precompila. Favicon * es simplemente un ejemplo *. Cuando salgo de favicon, el problema persiste y sale a la superficie con el siguiente activo: un archivo js o css. – berkes

Cuestiones relacionadas