Jestem całkiem nowy w bundlerze i kapistranie i próbuję używać ich razem. Kiedy próbuję wdrożyć, otrzymuję komunikat:
Próbujesz zainstalować w trybie wdrażania po zmianie pliku Gemfile. Uruchom `` instalację pakietu '' w innym miejscu i dodaj zaktualizowany plik Gemfile.lock do kontroli wersji.
Nie wiem, jak zadowolić system, który narzeka, i nie rozumiem, dlaczego skarga się pojawia, ponieważ przeczytałem w dokumencie :
Jeśli Gemfile.lock istnieje i zaktualizowałeś swój Gemfile (5), bundler użyje zależności w Gemfile.lock dla wszystkich klejnotów, których nie aktualizowałeś, ale ponownie rozwiąże zależności klejnotów, które zaktualizowałeś . Więcej informacji na temat tego procesu aktualizacji można znaleźć poniżej w sekcji AKTUALIZACJA KONSERWACYJNA.
Interpretuję to w ten sposób, że Bundler poradzi sobie z faktem, że mój plik Gemfile nie jest tym, czego oczekiwał. Jakaś pomoc?
Specyfikacje: Ruby 1.9.3, Rails 3.2.3, Capistrano 2.12.0, Bundler 1.1.4, Windows 7, wdrażanie na maszynie Posix.
Edycja: My Gemfile zawiera bloki logiczne, takie jak następujące:
unless RbConfig::CONFIG['host_os'] === 'mingw32'
# gem 'a' ...
end
źródło
unless RbConfig::CONFIG['host_os'] === 'mingw32'
? (Ergo powinno zawierać różne elementy na moim komputerze z systemem Windows niż na serwerze linux.):platforms
flagi dla klejnotów, których potrzebował mój serwer prod (posix), ale których nie było na moim serwerze deweloperskim (wygrywającym), spowodowało różnicę:platforms :ruby do; gem 'mygem'; ...; end
(Otrzymujesz zielony znak wyboru, jeśli nie masz nic przeciwko dodaniu tej instrukcji do odpowiedzi.):require
, działa też dobrze stackoverflow.com/a/16475580/933358vi .bundle / config
zmień opcję BUNDLE_FROZEN z „1” na „0”
wykonaj „instalację pakietową”
LUB
uruchom „konfigurację pakietu”
sprawdź, czy „zamrożona” wartość jest prawdziwa, ustaw ją na fałsz
konfiguracja pakietu zamrożona - fałsz
źródło
bundle config frozen false
to moja gotowa poprawka. Wielkie dzięki, za dwa lata! Wydaje mi się, że odpowiedź Joshua Pintera odnosi się do powyższego komentarza - może to być wpływ globalnej konfiguracji Bundlera.bundle config frozen false
nic dla mnie nie zrobił. Przyjęty do edycji .bundle / config, w którym wpis BUNDLE_FROZEN = "true" (tekstowy prawda)Uważaj na globalną konfigurację Bundler.
Miałem globalną konfigurację w moim środowisku deweloperskim w
~/.bundle/config
, ponieważ nie miałem w moim środowisku CI / Production, co spowodowało,Gemfile.lock
że to, co zostało wygenerowane w moim środowisku deweloperskim, różniło się od tego w moim środowisku CI / Production.W moim przypadku ustawiłem
github.https
na true w moim środowisku deweloperskim, ale nie miałem takiej konfiguracji w moim środowisku CI / Production. To spowodowało, że te dwaGemfile.lock
pliki były różne.źródło
Kiedy zobaczysz następujące ...
$ bundle install You are trying to install in deployment mode after changing your Gemfile. Run `bundle install` elsewhere and add the updated Gemfile.lock to version control. If this is a development machine, remove the Gemfile freeze by running `bundle install --no-deployment`. You have added to the Gemfile: * source: rubygems repository https://rubygems.org/ * rails (~> 3.2) . . .
... Wtedy najprawdopodobniej masz nieaktualne pliki .gem w katalogu vendor / cache.
Być może wcześniej biegałeś
$bundle install --deployment
który umieścił w pamięci podręcznej jakieś "nieaktualne" pliki .gem?W każdym razie możesz obejść ten błąd, uruchamiając:
bundle install --no-deployment
To jedna z wielu wspaniałych rzeczy w Railsach ... komunikaty o błędach często mówią dokładnie, co zrobić, aby rozwiązać problem.
źródło
Mój konkretny problem był związany z tym, co zgłosił @JoshPinter, tj. Rozbieżności między hostami typu dev-vs-deploy w protokole używanym przez bundler do pobierania klejnotów z github.
Krótko mówiąc, wystarczyło zmodyfikować następujący
Gemfile
wpis ...gem 'activeadmin', github: 'activeadmin'
... do tej bezpiecznej składni ( patrz odniesienie ):
gem 'activeadmin', git: 'https://github.com/activeadmin/activeadmin.git'
Moje wdrożenia wróciły do normy.
źródło
Rozwiązanie dla mnie było nieco inne niż wszystkie wymienione tutaj. Próbowałem zaktualizować sidekiq do sidekiq-pro (co wymaga pakietu w wersji 1.7.12+), ale ciągle otrzymywałem komunikat „Próbujesz zainstalować w trybie wdrażania po zmianie pliku Gemfile” z travis-ci
Sprawdzanie wyjścia konsoli travis-ci ujawniło, że używana była starsza wersja bundlera.
W moim przypadku musiałem edytować plik travis.yml, aby dodać:
before_install: - gem update bundler
To zmusiło Travis-ci do korzystania z najnowszej wersji bundlera i spowodowało zniknięcie komunikatu o błędzie.
źródło
cap shell
igem update bundler
lubwith <role> gem update bundler
lubon <machine> gem update bundler
Nie obchodzi mnie to. To właśnie zrobiłem. Naprawiło to.
rm -rf .bundle rm -rf Gemfile.lock bundle install
źródło
rm -fr .bundle
Naprawiono problem za mnie.
źródło
Wcześniej spotkałem coś podobnego. Myślę, że jednym ze sposobów rozwiązania tego problemu, który może zająć więcej miejsca na serwerze, niż chcesz, jest uruchomienie
bundle install --deployment
a następnie spróbuj wdrożyć. Robi to coś w rodzaju instalowania wszystkich twoich klejnotów w folderze dostawcy, którego uważam, że ogólnie dobrze jest unikać ... ale prawdopodobnie nadal będzie działać. Kiedyś moja aplikacja zachowywała się w ten sposób, moim rozwiązaniem było usuwanie dokładnych wersji do pobrania z mojego pliku Gemfile, a następnie ponowne łączenie i wdrażanie.
gem 'rails_admin', :git => 'git://github.com/sferik/rails_admin.git', :branch => 'master'
do
gem 'rails_admin'
Możesz też zrobić to, co sugeruje, i przenieść projekt z serwera produkcyjnego na maszynę lokalną, spakować go, a następnie przesłać ponownie na serwer. To rozwiązanie może nie być w 100% poprawne, ale niektóre z nich działały dla mnie ... po prostu pomyślałem, że się podzielę. Powodzenia
źródło
--deployment
Flaga nie zrobić różnicę chyba Usunąłem Gemfile.lock. Czy tak właśnie powinno być?Inna przyczyna błędu:
To trochę głupie, ale jestem pewien, że ktoś inny popełni ten sam błąd.
Dla Rails 4 Heroku dodał gem rails_12factor. Jeśli używałeś go, zanim go dodali, będziesz mieć te dwa klejnoty:
gem 'rails_log_stdout', github: 'heroku/rails_log_stdout' gem 'rails3_serve_static_assets', github: 'heroku/rails3_serve_static_assets'
Musisz je usunąć, kiedy dodajesz nowy. (są dołączone). Myślę, że ujdzie ci to na sucho, dopóki nie dotkniesz ich linii w pliku z klejnotami, po czym Heroku zauważy duplikację i woła z powyższym błędem.
powodzenia z Railsami 4.
źródło
W naszym przypadku używaliśmy funkcji, która nie była dostępna w starej wersji pakietu, który działał na naszej maszynie produkcyjnej. Dlatego wystarczyło zaktualizować bundler, czyli zrobić
gem update bundler
.źródło
Może to być niebezpieczny pomysł, ale jeśli absolutnie musisz coś przetestować w środowisku wdrażania produkcyjnego, możesz edytować plik .bundle / config
# This value is normally '1' # Set it to '0' BUNDLE_FROZEN: '0'
Teraz wywołaj pakiet, w moim przypadku musiałem zaktualizować określony klejnot, więc to moje polecenie
RAILS_ENV=production bundle update <whatever gem>
Prawdopodobnie powinieneś zmienić to z powrotem po aktualizacji, więc później wszystko będzie działać zgodnie z oczekiwaniami. Ponownie, prawdopodobnie jest to nieobsługiwane i YMMV
źródło
Wpadłem na to, wdrażając aplikację Nesta po kilku aktualizacjach klejnotów. Pomogło mi usunięcie pliku Gemfile.lock , uruchomienie go w
bundle install
celu ponownego wygenerowania i ponowne wdrożenie.źródło
Natknąłem się na podobny problem, ale zrobiłem jedno
bundle install
i drugie,bundle update
a Heroku nadal odrzuciło mój atak.Naprawiłem problem, po prostu usuwając Gemfile.lock, a następnie uruchamiając
bundle install
ponownie. Następnie dodałem, zatwierdziłem i wrzuciłem to do mojego repozytorium git. Po tym nie miałem problemu z przejściem do Heroku.źródło
w przypadku heroku nie musisz zmieniać składni w
Gemfile
. możesz po prostu dodaćBUNDLE_GITHUB__HTTPS
(zwróć uwagę na podwójne podkreślenie) jako zmienną środowiskową i ustawić ją natrue
(na pulpicie nawigacyjnym aplikacji heroku podSettings
zakładką wConfig Vars
sekcji). spowoduje to zmianę protokołu zgit://
nahttps://
dla wszystkich takich żądań.źródło
Otrzymałem komunikat o błędzie podczas próby wypchnięcia do Heroku. Znalazłem naprawione następujące rozwiązanie.
źródło
Ten problem może być związany z podmodułami wskazującymi na stare wersje kodu. W moim przypadku rozwiązałem ten problem, aktualizując moje moduły podrzędne
Jeśli masz moduły podrzędne, spróbuj uruchomić:
git submodule update --init
bundle install
źródło
Po tym poleceniu możesz ponownie przeprowadzić normalną instalację pakietu:
bundle install --no-deployment
źródło
Przeczytałem kilkanaście rozwiązań z różnych zasobów, ale nie znalazłem dokładnie, co mogłoby mi pomóc w tej sytuacji
Więc znalazłem rozwiązanie. Dokładnie mówiąc, uważnie przeczytałem komunikat o błędzie i było rozwiązanie: Uruchom instalację pakietu w innym miejscu . „Gdzie indziej” to moja Cloud9, w której opracowałem moją aplikację. Więc moje kroki
rsync
poleceniabundle install
. w takim przypadku będziesz mieć zmienioną wersję Gemfile.lockrsync
bundle install --deployment --without development test
GOTOWE! Życzę wszystkim powodzenia!źródło