Pakiet: próbujesz zainstalować w trybie wdrażania po zmianie pliku Gemfile

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

Komunikat o błędzie jesteś coraz czasowo Gemfile.lockmoże być spowodowane Gemfilei Gemfile.locknie zgadzają się ze sobą. Wygląda na to, że zmieniłeś coś w swoim Gemfile od czasu ostatniego uruchomienia bundle install(lub update). Kiedy ty bundle install, aktualizuje twój Gemfile.lock o wszelkie zmiany wprowadzone w Gemfile.

Upewnij się, że uruchamiasz bundle installlokalnie, a następnie zarejestruj się, aby kontrolować źródło nowo zaktualizowanego Gemfile.lockpliku. Następnie spróbuj wdrożyć.

Edycja : jak stwierdzono w komentarzach, warunek w Gemfile spowodował, że poprawny Gemfile.lock na jednej platformie, nieważny na innej. Podanie flagi : platform dla tych klejnotów zależnych od platformy w pliku Gemfile powinno rozwiązać asymetrię.

vi .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

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.httpsna true w moim środowisku deweloperskim, ale nie miałem takiej konfiguracji w moim środowisku CI / Production. To spowodowało, że te dwa Gemfile.lockpliki były różne.

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.

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 Gemfilewpis ...

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.

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.

Nie obchodzi mnie to. To właśnie zrobiłem. Naprawiło to.

rm -rf .bundle 
rm -rf Gemfile.lock
bundle install

rm -fr .bundle

Naprawiono problem za mnie.

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

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.

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.

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

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 installcelu ponownego wygenerowania i ponowne wdrożenie.

Natknąłem się na podobny problem, ale zrobiłem jedno bundle installi drugie, bundle updatea Heroku nadal odrzuciło mój atak.

Naprawiłem problem, po prostu usuwając Gemfile.lock, a następnie uruchamiając bundle installponownie. 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.

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ą na true(na pulpicie nawigacyjnym aplikacji heroku pod Settingszakładką w Config Varssekcji). spowoduje to zmianę protokołu z git://na https://dla wszystkich takich żądań.

Otrzymałem komunikat o błędzie podczas próby wypchnięcia do Heroku. Znalazłem naprawione następujące rozwiązanie.

1. Git pull origin master
2. Stan Git
3. Git commit
4. Wzorzec pochodzenia Git push
5. Git push heroku master

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

Po tym poleceniu możesz ponownie przeprowadzić normalną instalację pakietu:

bundle install --no-deployment

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

1. skopiuj Gemfile i Gemfile.lock z serwera na komputer lokalny za pomocą rsync polecenia
2. wstaw te dwa pliki do mojego projektu RoR (użyłem Cloud9)
3. otwórz Gemfile i wprowadź zmiany, które chcę. W moim przypadku dodałem klejnot `` cienki ''
4. na płycie CD terminala do mojej aplikacji na Cloud9 i uruchom bundle install. w takim przypadku będziesz mieć zmienioną wersję Gemfile.lock
5. skopiuj nowe Gemfile i Gemfile.lock na serwer używającrsync
6. cd do mojego folderu aplikacji i ponownie uruchom bundle install --deployment --without development test GOTOWE! Życzę wszystkim powodzenia!