2015-04-14 14 views
14

Uruchomiłem bundle update i zaktualizowałem sprockets do wersji 3.0.0.Capistrano 3 + Sprockets 3 + Rails 4.2.1 nie zostaną wdrożone?

Kiedy próbuję wdrożyć poprzez Kapistrana 3 pojawia się następujący błąd:

INFO [e54ac5ca] Running /usr/bin/env cp /var/www/testapp/releases/20150414002210/public/assets/manifest* /var/www/testapp/releases/20150414002210/assets_manifest_backup as [email protected] 
DEBUG [e54ac5ca] Command: cd /var/www/testapp/releases/20150414002210 && /usr/bin/env cp /var/www/testapp/releases/20150414002210/public/assets/manifest* /var/www/testapp/releases/20150414002210/assets_manifest_backup 
DEBUG [e54ac5ca] cp: cannot stat ‘/var/www/testapp/releases/20150414002210/public/assets/manifest*’ 
DEBUG [e54ac5ca] : No such file or directory 
DEBUG [d2c5a990] cp: cannot stat ‘/var/www/testapp/releases/20150414002210/public/assets/manifest*’ 
DEBUG [d2c5a990] : No such file or directory 
cap aborted! 
SSHKit::Runner::ExecuteError: Exception while executing as [email protected]: cp exit status: 1 
cp stdout: Nothing written 
cp stderr: cp: cannot stat ‘/var/www/testapp/releases/20150414002210/public/assets/manifest*’: No such file or directory 
/Users/HomeHome/.rvm/gems/ruby-2.1.3/gems/sshkit-1.7.1/lib/sshkit/runners/parallel.rb:16:in `rescue in block (2 levels) in execute' 
/Users/HomeHome/.rvm/gems/ruby-2.1.3/gems/sshkit-1.7.1/lib/sshkit/runners/parallel.rb:12:in `block (2 levels) in execute' 
SSHKit::Command::Failed: cp exit status: 1 
cp stdout: Nothing written 
cp stderr: cp: cannot stat ‘/var/www/testapp/releases/20150414002210/public/assets/manifest*’: No such file or directory 
/Users/HomeHome/.rvm/gems/ruby-2.1.3/gems/sshkit-1.7.1/lib/sshkit/command.rb:95:in `exit_status=' 
/Users/HomeHome/.rvm/gems/ruby-2.1.3/gems/sshkit-1.7.1/lib/sshkit/backends/netssh.rb:179:in `block in _execute' 
/Users/HomeHome/.rvm/gems/ruby-2.1.3/gems/sshkit-1.7.1/lib/sshkit/backends/netssh.rb:133:in `tap' 
/Users/HomeHome/.rvm/gems/ruby-2.1.3/gems/sshkit-1.7.1/lib/sshkit/backends/netssh.rb:133:in `_execute' 
/Users/HomeHome/.rvm/gems/ruby-2.1.3/gems/sshkit-1.7.1/lib/sshkit/backends/netssh.rb:66:in `execute' 
/Users/HomeHome/.rvm/gems/ruby-2.1.3/gems/capistrano-rails-1.1.2/lib/capistrano/tasks/assets.rake:68:in `block (5 levels) in <top (required)>' 
/Users/HomeHome/.rvm/gems/ruby-2.1.3/gems/sshkit-1.7.1/lib/sshkit/backends/abstract.rb:77:in `within' 
/Users/HomeHome/.rvm/gems/ruby-2.1.3/gems/capistrano-rails-1.1.2/lib/capistrano/tasks/assets.rake:67:in `block (4 levels) in <top (required)>' 
/Users/HomeHome/.rvm/gems/ruby-2.1.3/gems/sshkit-1.7.1/lib/sshkit/backends/netssh.rb:54:in `instance_exec' 
/Users/HomeHome/.rvm/gems/ruby-2.1.3/gems/sshkit-1.7.1/lib/sshkit/backends/netssh.rb:54:in `run' 
/Users/HomeHome/.rvm/gems/ruby-2.1.3/gems/sshkit-1.7.1/lib/sshkit/runners/parallel.rb:13:in `block (2 levels) in execute' 
Tasks: TOP => deploy:assets:backup_manifest 
(See full trace by running task with --trace) 
The deploy has failed with an error: #<SSHKit::Runner::ExecuteError: Exception while executing as [email protected]: cp exit status: 1 
cp stdout: Nothing written 
cp stderr: cp: cannot stat ‘/var/www/testapp/releases/20150414002210/public/assets/manifest*’: No such file or directory 

Szukałem dookoła dla osób ewentualnie mających te same problemy i wydaje się, nie ma problemów lub komentarze na nim wszędzie ...

Szczerze, nie jestem nawet pewien, w jaki sposób sprockets, sprockets-rails są powiązane z szynami. To wszystko jest dla mnie dość mylące ... na przykład domyślny Gemfile, który jest dostarczany ze świeżą aplikacją Rails 4.2.1, mówi, że zębatki 3.0.0 są dozwolone w Gemfile.lock, ale kiedy przejdziesz do przewodnika uaktualnień 2-> 3, pokazuje on, że //= include został usunięty, ale znajduje się właśnie w pliku application.js.

Może brakuje mi czegoś, ale nie jestem całkiem pewien, jak rozwiązać ten problem.

Odpowiedz

7

Problem jest łatwy do naprawienia, ale myślę, że najpierw powinniśmy odpowiedzieć na kilka innych pytań.

sprockets to biblioteka rubinowa, która automatyzuje zarządzanie zasobami frontowymi (CSS, JS, obrazy itp.).

Jest on oparty na idei utrzymywania plików aktywów logicznie zorganizowane w rozwoju, a następnie łańcuch i minify je przed wdrożeniem do produkcji. Koła zębate umożliwiają ten proces automatycznie.

Rails 3.1 (dawno temu, teraz) opublikował nową funkcję o nazwie "Asset Pipeline", która zautomatyzowała zarządzanie zasobami internetowymi. Rurowy zasób Railsów był i nadal jest zasilany przez sprockets.

Zarówno sprockets, jak i rails są aktywnie utrzymywane i rozwijane biblioteki. Nowe wersje są wydawane z nowymi funkcjami i łamaniem zmian.
Uważam, że Rails nie używa domyślnie najnowszej wersji sprockets. To jest ok, mówimy o kompilowaniu CSS i JS tutaj, bez interakcji z zewnętrznym API; nawet stara wersja sprockets może wykonać to zadanie.
Oznacza to, że aktualizacja sprockets nie jest dobrym pomysłem. Każda wersja Railsów deklaruje konkretną (min-max) wersję sprockets, nie bez powodu: jest to wersja, na której opiera się obecny Asset Pipeline. Aktualizacja może spowodować problemy.

Następnie przejdźmy do pliku manifestu.
Domyślnie po wstępnej kompilacji zasobów (rozwiązywanie odniesień, w tym niektóre pliki do innych, łańcuchy i ich minimalizowanie), zebrane zasoby są kopiowane w RAILS_ROOT/public/assets. Dzięki nim Rails generuje plik manifest, który zawiera listę wszystkich prekompilowanych zasobów. W twojej wersji Railsów powinno być manifest.json, ale kiedyś było to manifest.yml.

Teraz ostatni element układanki to capistrano, który mogę sobie wyobrazić.

Linia:

cp: cannot stat ‘/var/www/testapp/releases/20150414002210/public/assets/manifest*’ 

oznacza, że ​​capistrano próbowali znaleźć plik w katalogu RAILS_ROOT/public/assetsmanifest. Ta wieloznaczna jest dostępna, ponieważ może być manifest.json lub manifest.yml, w zależności od wersji Rails.
Ponadto, stat oznacza, że ​​próbuje uzyskać pewne informacje z pliku, prawdopodobnie po to, aby dowiedzieć się, jaka jest aktualna.

Problem polega na tym, że plik nie istnieje.
Powinieneś precompile the assets, następnie zatwierdzić wygenerowane pliki i spróbować ponownie wdrożyć.

+11

Właściwie nie trzeba do precompile aktywów lokalnie i zobowiązać je do przechowalni później. To błąd, a kolesie z capistrano-rails pracują nad tym teraz: https://github.com/capistrano/rails/pull/112 & https://github.com/capistrano/rails/issues/111 mimo to , Kciuki za tak szczegółową odpowiedź! –

+1

Och, miłe informacje, dzięki. Podczas wdrażania z capistrano zawsze wolę strategię wdrażania, która używa gałęzi _deploy_, więc "skompilowane zasoby zatwierdzone" nie będą zanieczyszczać twojego _master_. Ponadto, częściej będziesz wdrażać do klastra serwerów i uważam, że nieefektywne jest ich kompilowanie na każdym serwerze, na którym się wdrażasz. Ponadto prekompilowanie ich lokalnie ułatwia automatyzację (w ramach zadania cap caploy) przesłanie ich do CDN. – tompave

+4

Aby rozwinąć komentarz z @mid, stało się, że koło zębate 3.0.0 [wprowadzono zmianę] (https://github.com/rails/sprockets/commit/ce6508e8540f829c6221afa39fdf718e4dded096), w którym zmieniło nazwę pliku manifestu z pliku manifest.json do .sprockets-manifest.json. Jesteśmy w trakcie aktualizacji szyn kaskadowych w celu sprawdzenia obu nazw plików i użycia tego, który znajdzie. –

22

Jeśli używasz capistrano-rails, spróbuj zaktualizować do 1.1.3. Naprawiło to problem dla mnie.

capistrano-rails CHANGELOG:

1.1.3 (Apr 18 2015) 
- Fixed no_release behaviour (https://github.com/capistrano/rails/pull/95) 
- Allow assets manifest backup with folder "manifests" (https://github.com/capistrano/rails/pull/92) 
- Handle Sprocket 3 manifest filename 
+3

dziękuję bardzo !!! dla innych manekinów jak ja - w wersji gemfile set bezpośrednio klejnot "capistrano-rails", "~> 1.1.3" – kpblc

4

za komentarz, naprawiłem to przez uaktualnienie CAPISTRANO szyn z 1.1.2 -> 1.1.3

# Gemfile 
'capistrano-rails', '~> 1.1.3'