Bundler: Sie versuchen, im Bereitstellungsmodus zu installieren, nachdem Sie Ihre Gemfile geändert haben

Ich bin ziemlich neu in Bundler und Capistrano und versuche, sie zusammen zu verwenden. Wenn ich versuche bereitzustellen, wird folgende Meldung angezeigt:

Sie versuchen, im Bereitstellungsmodus zu installieren, nachdem Sie Ihre Gemfile geändert haben. Führen Sie die Bundle-Installation an einer anderen Stelle aus und fügen Sie die aktualisierte Datei Gemfile.lock zur Versionskontrolle hinzu.

Ich weiß nicht, wie ich das System befriedigen soll, das sich beschwert, und ich verstehe nicht, warum die Beschwerde auftaucht, weil ich im Dokument gelesen habe :

Wenn eine Gemfile.lock vorhanden ist und Sie Ihre Gemfile (5) aktualisiert haben, verwendet der Bundler die Abhängigkeiten in der Gemfile.lock für alle Gems, die Sie nicht aktualisiert haben, löst jedoch die Abhängigkeiten der Gems, die Sie aktualisiert haben, erneut auf . Weitere Informationen zu diesem Aktualisierungsprozess finden Sie unten unter KONSERVATIVES UPDATING.

Ich interpretiere das so, dass der Bundler damit umgehen kann, dass mein Gemfile nicht das ist, was er erwartet hat. Irgendeine Hilfe?

Technische Daten: Ruby 1.9.3, Rails 3.2.3, Capistrano 2.12.0, Bundler 1.1.4, Windows 7, Bereitstellung auf einem Posix-Computer.

Bearbeiten: Meine Gemfile enthält Logikblöcke wie die folgenden:

unless RbConfig::CONFIG['host_os'] === 'mingw32'
  # gem 'a' ...
end

Die Fehlermeldung Sie in Bezug auf immer Gemfile.locksein kann , weil Ihr Gemfileund Gemfile.locknicht miteinander übereinstimmen. Es hört sich so an, als hätten Sie etwas in Ihrer Gemfile geändert, seit Sie das letzte Mal ausgeführt haben bundle install(oder update). Wenn Sie bundle install, aktualisiert es Ihre Gemfile.lock mit allen Änderungen, die Sie an Gemfile vorgenommen haben.

Stellen Sie sicher, dass Sie bundle installlokal ausgeführt werden, und checken Sie ein , um Ihre neu aktualisierten Daten anschließend zu steuern Gemfile.lock. Versuchen Sie dann die Bereitstellung.

Bearbeiten : Wie in den Kommentaren erkannt, führte eine Bedingung in der Gemfile zu einer gültigen Gemfile.lock auf einer Plattform, die auf einer anderen ungültig ist. Das Bereitstellen eines : Plattform- Flags für diese plattformabhängigen Edelsteine ​​in der Gem-Datei sollte die Asymmetrie lösen.

vi .bundle / config

Ändern Sie die Option BUNDLE_FROZEN von '1' auf '0'.

"Bundle installieren"

ODER

Führen Sie "bundle config" aus.

Überprüfen Sie, ob der Wert "eingefroren" auf "wahr" gesetzt ist

Bundle-Konfiguration eingefroren false

Achten Sie auf die globale Bundler-Konfiguration.

Ich hatte eine globale Konfiguration in meiner Entwicklungsumgebung ~/.bundle/config, die ich in meiner CI / Produktionsumgebung nicht hatte, was dazu führte, Gemfile.lockdass sich die in meiner Entwicklungsumgebung generierte Konfiguration von der in meiner CI / Produktionsumgebung unterschied.

In meinem Fall habe ich github.httpsin meiner Entwicklungsumgebung auf true gesetzt, aber in meiner CI / Production-Umgebung keine solche Konfiguration gehabt. Dies führte dazu, dass die beiden Gemfile.lockDateien unterschiedlich waren.

Wenn Sie Folgendes sehen ...

$ 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)
. . .

... Dann ist das Problem höchstwahrscheinlich, dass Sie veraltete .gem-Dateien in Ihrem Vendor / Cache-Verzeichnis haben.

Vielleicht haben Sie zuvor $bundle install --deploymenteinige "veraltete" .gem-Dateien in den Cache gestellt?

In jedem Fall können Sie diesen Fehler umgehen, indem Sie Folgendes ausführen: bundle install --no-deployment

Das ist eines der vielen großartigen Dinge an Rails ... Die Fehlermeldungen sagen Ihnen oft genau, was Sie tun müssen, um das Problem zu beheben.

Die Lösung war für mich etwas anders als die anderen hier aufgeführten. Ich habe versucht, ein Upgrade von sidekiq auf sidekiq-pro durchzuführen (für das Bundler 1.7.12+ erforderlich ist), aber ich habe immer wieder die Meldung "Sie versuchen, im Bereitstellungsmodus zu installieren, nachdem Sie Ihre Gemfile geändert haben" von travis-ci erhalten

Die Überprüfung der Konsolenausgabe von travis-ci ergab, dass eine ältere Version von Bundler verwendet wurde.

In meinem Fall musste ich die Datei travis.yml bearbeiten, um Folgendes hinzuzufügen:

before_install: - gem update bundler

Dies zwang travis-ci, die neueste Version von Bundler zu verwenden, und ließ die Fehlermeldung verschwinden.

Mein spezifisches Problem hing mit dem zusammen, was von @JoshPinter gemeldet wurde, dh mit Abweichungen zwischen Entwickler und Bereitstellungshost im Protokoll, das vom Bundler zum Abrufen von Edelsteinen aus Github verwendet wurde.

Um es kurz zu machen, ich musste nur den folgenden GemfileEintrag ändern ...

gem 'activeadmin', github: 'activeadmin'

... zu dieser sicheren Syntax ( siehe Referenz ):

gem 'activeadmin', git: 'https://github.com/activeadmin/activeadmin.git'

Und meine Bereitstellungen sind wieder normal.

Es ist mir egal. Das habe ich getan. Es hat es behoben.

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

rm -fr .bundle

Das Problem wurde für mich behoben.

Ich bin schon einmal auf etwas Ähnliches gestoßen. Ich denke, eine Möglichkeit, das Problem zu beheben, aber möglicherweise mehr Speicherplatz auf Ihrem Server beansprucht, als Sie möchten, ist das Ausführen

bundle install --deployment 

und versuchen Sie dann, bereitzustellen. Dies funktioniert so etwas wie die Installation all Ihrer Edelsteine ​​im Lieferantenordner, was meiner Meinung nach im Allgemeinen gut zu vermeiden ist ... aber wahrscheinlich trotzdem funktionieren wird. Meine App hat sich früher so verhalten. Meine Lösung bestand darin, genaue Versionen zu entfernen, die in meiner Gemfile heruntergeladen werden sollten, und sie dann neu zu bündeln und bereitzustellen.

gem 'rails_admin', :git => 'git://github.com/sferik/rails_admin.git', :branch => 'master'

zu

gem 'rails_admin'

Oder Sie können das tun, was es vorschlägt, und Ihr Projekt vom Produktionsserver auf einen lokalen Computer übertragen, bündeln und dann erneut auf Ihren Server übertragen. Diese Lösung ist möglicherweise nicht 100% korrekt, aber ein Teil davon hat bei mir funktioniert ... dachte nur, ich würde sie teilen. Viel Glück

Eine weitere Fehlerursache:

Das ist ein bisschen dumm, aber ich bin sicher, dass jemand anderes den gleichen Fehler machen wird.

Für Rails 4 hat Heroku den Edelstein Rails_12Factor hinzugefügt. Wenn Sie es verwendet haben, bevor sie es hinzugefügt haben, haben Sie diese beiden Edelsteine:

gem 'rails_log_stdout',  github: 'heroku/rails_log_stdout'
gem 'rails3_serve_static_assets', github: 'heroku/rails3_serve_static_assets'

Sie müssen sie entfernen, wenn Sie die neue hinzufügen. (Sie sind enthalten). Ich denke, Sie können damit durchkommen, bis Sie die Zeilen in Ihrer Edelsteindatei berühren. Dann bemerkt Heroku die Duplizierung und schreit mit dem obigen Fehler.

Viel Glück mit Rails 4.

In unserem Fall haben wir eine Funktion verwendet, die in einer alten Version von Bundler, die auf unserer Produktionsmaschine ausgeführt wurde, nicht verfügbar war. Daher war es ausreichend, den Bundler zu aktualisieren, dh a gem update bundler.

Dies mag eine gefährliche Idee sein, aber wenn Sie unbedingt etwas in einer Produktionsbereitstellungsumgebung testen müssen, können Sie die .bundle / config-Datei bearbeiten

# This value is normally '1' 
# Set it to '0'
BUNDLE_FROZEN: '0'

Rufen Sie jetzt Bundle auf, in meinem Fall musste ich ein bestimmtes Juwel aktualisieren, also ist dies mein Befehl

RAILS_ENV=production bundle update <whatever gem>

Sie sollten es wahrscheinlich nach dem Update wieder ändern, damit die Dinge danach wie erwartet funktionieren. Auch dies wird wahrscheinlich nicht unterstützt und YMMV

Nach einigen Juwelen-Updates bin ich auf diese Bereitstellung einer Nesta-App gestoßen. Für mich hat es funktioniert , die Datei Gemfile.lock zu löschen, auszuführen , um bundle installsie neu zu generieren, und erneut bereitzustellen .

Ich lief in ein ähnliches Problem aber ich tat beides bundle installund bundle updateund Heroku abgelehnt noch meinen Push.

Ich habe das Problem behoben, indem ich Gemfile.lock gelöscht und dann bundle installerneut ausgeführt habe. Ich fügte dann hinzu, verpflichtete mich und schob das zu meinem Git-Repo. Danach hatte ich kein Problem damit, nach Heroku zu drängen.

Für Heroku müssen Sie die Syntax in der nicht ändern Gemfile. Sie können einfach BUNDLE_GITHUB__HTTPSeine Umgebungsvariable hinzufügen (beachten Sie den doppelten Unterstrich) und auf true(im Dashboard Ihrer Heroku-App unter der SettingsRegisterkarte im Config VarsAbschnitt) setzen. Dadurch wird das Protokoll für alle derartigen Anforderungen von git://auf https://umgeschaltet.

Ich hatte die Fehlermeldung, als ich versuchte, nach Heroku zu pushen. Ich fand die folgende Lösung behoben.

1. Git Pull Origin Master
2. Git Status
3. Git Commit
4. Git Push Origin Master
5. Git Push Heroku Master

Dieses Problem kann mit Submodulen zusammenhängen, die auf alte Codeversionen verweisen. Für mich habe ich dieses Problem durch Aktualisierung meiner Submodule behoben

Wenn Sie Submodule haben, versuchen Sie Folgendes auszuführen:

git submodule update --init

bundle install

Nach diesem Befehl können Sie Ihre normale Bundle-Installation erneut durchführen:

bundle install --no-deployment

Ich habe ein Dutzend Lösungen zu verschiedenen Ressourcen gelesen, aber nicht genau gefunden, was mir in dieser Situation helfen könnte

Also habe ich eine Lösung gefunden. Genau gesagt, ich habe die Fehlermeldung aufmerksam gelesen und es gab eine Lösung: Führen Sie die Bundle-Installation an einer anderen Stelle aus . "Anderswo" war meine Cloud9, in der ich meine App entwickelt habe. Also meine Schritte

1. Kopieren Sie Gemfile und Gemfile.lock vom Server auf den lokalen Computer mit rsync Befehl
2. Fügen Sie diese beiden Dateien in mein RoR-Projekt ein (ich habe Cloud9 verwendet).
3. öffne Gemfile und nimm die gewünschten Änderungen vor. In meinem Fall habe ich Edelstein 'dünn' hinzugefügt.
4. im Terminal CD zu meiner App auf Cloud9 und ausführen bundle install. In diesem Fall haben Sie eine geänderte Version von Gemfile.lock
5. Kopieren Sie neue Gemfile und Gemfile.lock auf den Server mitrsync
6. CD in meinen App-Ordner und wieder bundle install --deployment --without development test FERTIG ausführen! Wünsche allen viel Glück!