Pipeline di asset di rails su staging: impronta digitale corretta ma 404ing

Question

Sto eseguendo Rails 3.1.3, che include Sprockets 2.0.3 come dipendenza.

Ho impostato il mio ambiente di staging per essere configurato come suggerisce la guida di Rails per la produzione.

config.serve_static_assets = false 
config.assets.compress = true 
config.assets.compile = false 
config.assets.digest = true 

ho incluso nel mio Capfile

load 'deploy' 
load 'deploy/assets' 

E asset ottenere precompilati come previsto in deploy.

In pubblico/beni, trovo le risorse come previsto con le impronte digitali.

application-bd402855d34fb61e0a1690da06f79f20.js 
application-bd402855d34fb61e0a1690da06f79f20.js.gz 
application-ed3f9a8d23992790841c11b6692fb576.css 
application-ed3f9a8d23992790841c11b6692fb576.css.gz 
...and a bunch of images... 

Quando carico la pagina, vedo i riferimenti corretti, le impronte digitali e tutto il resto.

<link href="/assets/application-ed3f9a8d23992790841c11b6692fb576.css" media="screen" rel="stylesheet" type="text/css"> 
<script src="/assets/application-bd402855d34fb61e0a1690da06f79f20.js" type="text/javascript"></script> 

Tuttavia, tutto 404s, css, js, immagini, tutto.

Qualcuno sa qual è l'affare? Grazie!

Answer 1

config.assets.compile = false 

dovrebbe essere:

config.assets.compile = true 

Inoltre, assicurarsi che svuotare la cache:

bundle exec rake tmp:cache:clear 

e riavviare il server.

Answer 2

config.assets.compile = false 

Dovrebbe essere vero

Answer 3

Nonostante suggerimenti in altre risposte

config.assets.compile = true 

... è una soluzione, non una soluzione. Questa opzione consente a Rails di tornare alla compilazione al volo di asset che non possono essere trovati in pubblico/risorse. Può 'risolvere' il tuo problema in fase di staging ma avere Rails compilare risorse in fase di esecuzione non è esattamente ottimale nella produzione.

Mi ricordo nei primi mesi di lavoro con la nuova pipeline di asset in Rails 3.1.x che ho avuto problemi con la compressione e la generazione di digest che ho risolto solo in versioni successive. Suggerirei di provare

config.assets.compress = false 
config.assets.digest = false 

sia individualmente che insieme. E/o aggiornare alle versioni successive di Rails o alle gemme della pipeline degli asset.

Answer 4

Mi sono imbattuto nello stesso problema pochi mesi fa. Per alcuni motivi ho scelto di attivare manualmente la compilazione degli asset in produzione, quindi la mia produzione.rb ha

config.assets.compile = false 

e distribuzione Capistrano ha anche un compito di precompilare il patrimonio (utilizzando rvm così):

run "cd #{release_path} && RAILS_ENV=production bundle exec rake assets:precompile", shell: fetch(:rvm_shell) 

Il passo finale è fare in modo che abbiamo collegato simbolicamente la cartella asset in modo da non è necessario ricompilare le risorse che non sono state modificate.

Answer 5

Se si è certi che le risorse sono state compilate ed esistono nella directory pubblica, potrebbero essere le impostazioni del server Web? Sugli ambienti di produzione/staging le risorse non devono colpire l'app per rails ed essere servite direttamente dal server web. Ecco un esempio di frammento di configurazione di apache:

<LocationMatch "^/assets/.*$"> 
     Header unset ETag 
     FileETag None 
     # RFC says only cache for 1 year 
     ExpiresActive On 
     ExpiresDefault "access plus 1 year" 

     SetEnv no-gzip 
     RewriteEngine on 
     # Make sure the browser supports gzip encoding before we send it 
     RewriteCond %{HTTP:Accept-Encoding} \b(x-)?gzip\b 
     RewriteCond %{REQUEST_FILENAME}.gz -s 
     RewriteRule ^(.+) $1.gz [L] 

    </LocationMatch> 

    <FilesMatch \.css\.gz$> 
     ForceType text/css 
     Header set Content-Encoding gzip 
    </FilesMatch> 

    <FilesMatch \.js\.gz$> 
     ForceType text/javascript 
     Header set Content-Encoding gzip 
    </FilesMatch>