2011-10-26 8 views
10

Problem w pigułce polega na tym, że w trybie programistycznym wprowadziliśmy zmiany w plikach CSS lub JS, ale zawsze otrzymywaliśmy buforowane/stare wersje tych plików. Nic, co zrobiłem, nie miało żadnego skutku. Sprawdziłem dziesiątki razy konfigurację i wypróbowałem każdą kombinację wartości konfiguracyjnych, ale zawsze uzyskiwałem te same wyniki: stare/buforowane pliki. Musiałem uruchomić program w trybie produkcyjnym i zrestartować serwer po każdej zmianie do przetestowania.Rails 3.1.1 Potok potokowy Heroku caching gotcha

Spędziłem dni, wyrywając mi włosy z tego problemu, sprawdzając dziesiątki pytań o stackoverflow w strumieniu aktywów, ale nigdy nie znalazłem takiego, który by się do nich odnosił, więc pomyślałem, że opublikuję go tutaj dla potomności.

Używamy Heroku i prekompilujemy nasze zasoby, ponieważ Heroku nie może się przed nami prekompilować (używamy również narzędzia devise, które najwyraźniej jest przyczyną niepowodzenia prekompilacji heroku). Aby więc wypchnąć nasze prekompilowane aktywa do Heroku, musimy sprawdzić je w git.

Oto problem.

Po aktualizacji do Rails 3.1.1 prekompilacja zasobów wygenerowała pliki zarówno z hasłem MD5, jak i bez niego w nazwie. Nie zastanawiałem się nad tym zbyt długo i sprawdziłem wszystkie te pliki, więc mogłem naciskać na heroku. Jakiś czas później zauważyłem problem z buforowanymi wynikami w trybie programowania. Wstępnie skompilowane i sprawdzone zasoby bez skrótów MD5 były wyświetlane z/public/assets jako pliki statyczne, co uniemożliwiło nam zobaczenie jakichkolwiek zmian, które wprowadziliśmy w/app/assets.

Po tym, jak w końcu zdałem sobie z tego sprawę, uruchomiłem git rm/public/assets i wszystko znów działa. Więc na wynos: Uważaj, sprawdzaj aktywa w git!

Aby zmienić to w pytanie: jak inni to robią? Czy brakuje mi czegoś oczywistego? Naprawdę chciałbym, aby Heroku prekompilował moje zasoby dla mnie, ale nie udało mi się uzyskać błędu połączenia z bazą danych, który zbieram ze względu na programowanie. Miałem nadzieję, że Rails 3.1.1 to naprawił, ale tak się nie stało.

Odpowiedz

12

Czy sprawdziłeś to devise issue na github? Konkretnie Jose Valim mówi

Rails 3.1.1 final ma metodę zwaną config.assets.initialize_on_precompile. Jeśli ustawisz na wartość false, musisz być dobry, ale nie będziesz mógł uzyskać dostępu do informacji o modelu na swoich aktywach (prawdopodobnie nie powinieneś tego robić).

Może to pozwoli, aby prekompilacja wydarzyła się na Heroku dla ciebie.

+0

Dty, próbowałem tej dokładnej konfiguracji przed opublikowaniem tego pytania, ale nie działało dla mnie w tym czasie. Jednak po raz kolejny spróbowałem tego, tym razem z Devise 1.4.9 i oto i działa! Dzięki za sugestię, która sprawiła, że ​​spróbowałem ponownie. –

+0

@ JeffCutler-Stamm zadowolony, że się udało! Zajmuję się również aplikacją rails 3.1.1 na heroku, ale nie dodałem jeszcze narzędzia (ale wkrótce) – Dty

+1

Chciałbym zauważyć, że dodajesz to do config/application.rb –

0

Sprawdź this guide od Heroku. Przedstawiono w nim 3 sposoby wdrażania aplikacji Rails 3.1. Dwa z nich nie wymagają lokalnej prekompilacji.

+0

Dzięki - ale żaden z nich nie działa dla mnie. Jak wspomniałem w pytaniu, myślę, że jest to spowodowane opracowaniem. Prekompilacja podczas kompilacji slug zawsze kończy się niepowodzeniem z błędem połączenia z bazą danych. –

+0

mówisz, że kompilacja czasu wykonywania nie powiedzie się dla ciebie? –

+0

Tak, kompilacja środowiska wykonawczego kończy się niepowodzeniem, więc utknąłem w/precompilation przed popchnięciem do heroku. –

Powiązane problemy