2013-01-11 10 views
6

Ho un'applicazione Rails 3.2.3 di produzione che utilizzo per distribuire utilizzando capistrano. Quando ho deciso di aggiornare le rotaie a 3.2.11 ho fatto i seguenti passi:La distribuzione di Capistrano non riesce dopo l'aggiornamento a Rails 3.2.11

  1. cambiato versione rotaie in Gemfile
  2. run "fascio binari di aggiornamento"
  3. spinto nuove gemme da vendor/cache, Gemfile e Gemfile. bloccare
  4. run "Deploy produzione cap"

Capistrano ora non riesce con l'errore:

* 2013-01-11 15:58:25 executing `deploy:assets:precompile' 
    triggering before callbacks for `deploy:assets:precompile' 
    * 2013-01-11 15:58:25 executing `deploy:assets:update_asset_mtimes' 
    * executing "[ -e /home/deploy/projects/otv/shared/assets/manifest.yml ] && cat /home/deploy/projects/otv/shared/assets/manifest.yml || echo" 
    servers: ["xxx.xxx.99.51"] 
    [xxx.xxx.99.51] executing command 
    command finished in 28ms 
    * executing "cd -- /home/deploy/projects/otv/releases/20130111095812 && export LANG=en_US.UTF-8 && /usr/local/bin/bundle exec rake RAILS_ENV=production RAILS_GROUPS=assets assets:precompile && cp -- /home/deploy/projects/otv/shared/assets/manifest.yml /home/deploy/projects/otv/releases/20130111095812/assets_manifest.yml" 
    servers: ["xxx.xxx.99.51"] 
    [xxx.xxx.99.51] executing command 
** [out :: xxx.xxx.99.51] cp: cannot stat ‘/home/deploy/projects/otv/shared/assets/manifest.yml’: No such file or directory 
    command finished in 18773ms 

Ho provato a eseguire questi passaggi con altri progetti precedentemente utilizzati con successo con Capistrano con lo stesso risultato.

mio Gemfile and deploy.rb

risposta

4

FWIW, mi è stato sempre presente dopo l'aggiornamento a Capistrano> 2.14.0:

*** [err :: ourapp.net] cp: cannot stat `/home/deploy/www/ourapp/shared/assets/manifest.yml' 
*** [err :: ourapp.net] : No such file or directory 

Credo che un collegamento simbolico dei beni al comune dir lo aggiusterebbe, ma invece di fare casino (devo far distribuire questo), ho appena passato il cap indietro a 2.13.5.

+0

Grazie mille, Steve! –

+2

Sto usando capistrano 2.14.2 e vedo questo stesso problema dopo l'aggiornamento a Rails 4.0beta1. C'è qualche soluzione senza downgrade? - Non sono sicuro da dove collegheremo le risorse? –

+3

@RomanGaufman Il nome del file manifest è stato modificato in 'manifest-a5247d227d9b50f54f7c66dc7e640bca.json'. È possibile evitare questo errore creando semplicemente 'manifest.yml' dal comando' touch' nella directory '/ home/deploy/www/ourapp/shared/assets'. – Tsutomu

0

Hai cancellato tutti i vostri beni sul server remoto prima di aggiornare?

A volte alcuni vecchi riferimenti potrebbero causare questo tipo di problema

Cheers, Jérémy

+1

E pensare di eliminare Gemfile.lock dal modo in cui .. – Jeremy

+0

Non riesco a capire come eliminare i miei beni. ... la cartella projectpath/shared/assets è vuota, tutte le risorse ubicate in ... projectpath/releases/yyyymmddhhmmss/public/assets. Anche io non capisco come posso cancellare il mio Gemfile.lock, dovrei rimuoverlo dal repository perché il codice per la distribuzione è preso dal repository? –

+0

Bene, mantenere il tuo Gemfile.lock nel tuo repository non è una buona pratica, poiché viene generato automaticamente durante l'esecuzione di bundle (installazione, aggiornamento ..). Hai provato ad eseguire direttamente l'ultimo comando (eseguendo "cd -/home/deploy/projects/otv/releases/2 [....]) per esempio nella versione corrente ?! – Jeremy

1

ho avuto lo stesso problema.

Le nuove versioni di capistrano ora hanno some code per gestire il collegamento simbolico del percorso delle risorse condivise. Il mio config/deploy.rb aveva un codice per gestirlo e i percorsi erano in conflitto tra loro. Ho appena rimosso questa linea da esso per risolvere il problema:

run "ln -nfs #{shared_path}/public/assets #{release_path}/public/assets" 
Problemi correlati