Bundler: vous essayez d'installer en mode de déploiement après avoir modifié votre fichier Gemfile
Je suis assez novice chez bundler et capistrano et j'essaie de les utiliser ensemble. Lorsque j'essaie de déployer, je reçois le message suivant:
Vous essayez d'installer en mode de déploiement après avoir modifié votre fichier Gemfile. Exécutez `bundle install 'ailleurs et ajoutez le fichier Gemfile.lock mis à jour au contrôle de version.
Je ne sais pas comment satisfaire le système qui se plaint et je ne comprends pas pourquoi la plainte est en train d’être soulevée parce que j’ai lu dans le doc :
Si un fichier Gemfile.lock existe et que vous avez mis à jour votre fichier Gemfile (5), bundler utilisera les dépendances dans Gemfile.lock pour toutes les gemmes que vous n'avez pas mis à jour, mais que vous allez résoudre à nouveau les dépendances de gems que vous avez mis à jour. Vous pouvez trouver plus d'informations sur cette mise à jour processus ci-dessous sous MISE À JOUR CONSERVANTE.
J'interprète cela comme signifiant que le Bundler peut gérer le fait que mon Gemfile n'est pas ce qu'il attendait. De l'aide?
Spécifications: Ruby 1.9.3, Rails 3.2.3, Capistrano 2.12.0, Bundler 1.1.4, Windows 7, déploiement sur un ordinateur Posix.
Edit: Mon Gemfile comprend des blocs de code tels que:
unless RbConfig::CONFIG['Host_os'] === 'mingw32'
# gem 'a' ...
end
Le message d’erreur que vous obtenez concernant Gemfile.lock est peut-être dû au fait que vos Gemfile et Gemfile.lock ne sont pas d’accord. On dirait que vous avez changé quelque chose dans votre Gemfile depuis la dernière fois que vous avez exécuté bundle install (ou update). Lorsque vous bundle install, il met à jour votre fichier Gemfile.lock avec les modifications apportées à Gemfile.
Assurez-vous d’exécuter bundle install localement et d’enregistrer dans le contrôle de source votre Gemfile.lock nouvellement mis à jour par la suite. Ensuite, essayez de déployer.
Edit: comme indiqué dans les commentaires, une condition dans le fichier Gemfile entraînait la création d'un fichier Gemfile.lock valide sur une plate-forme et non valide sur une autre. Fournir un : platform flag pour ces gemmes dépendantes de la plate-forme dans Gemfile devrait résoudre l'asymétrie.
vi .bundle/config
changez l'option BUNDLE_FROZEN de '1' à '0'
faire "bundle install"
OR
lancer "bundle config"
voir si la valeur "frozen" est vraie, la mettre à faux
bundle config gelé faux
Surveillez la configuration globale de Bundler.
Ma configuration globale sur mon environnement de développement dans ~/.bundle/config était différente de celle que j'avais dans mon environnement de production/production; par conséquent, le Gemfile.lock généré dans mon environnement de développement était différent de celui de mon environnement de production/production.
Dans mon cas, je définissais github.https sur true dans mon environnement de développement, mais je n'avais pas cette configuration dans mon environnement CI/Production. Cela a entraîné une différence entre les deux fichiers Gemfile.lock.
Quand vous voyez ce qui suit ...
$ 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)
. . .
... Ensuite, le problème est probablement que vous ayez des fichiers .gem obsolètes dans votre répertoire vendeur/cache.
Peut-être avez-vous déjà exécuté $bundle install --deployment qui a mis dans le cache des fichiers .gem "obsolètes"?
Dans tous les cas, vous pouvez éviter cette erreur en exécutant: bundle install --no-deployment
C'est l'un des nombreux avantages de Rails ... Les messages d'erreur vous disent souvent exactement quoi faire pour résoudre le problème.
La solution pour moi était légèrement différente de celle proposée ici. J'essayais de passer de sidekiq à sidekiq-pro (ce qui nécessite le bundle 1.7.12+), mais le message "Vous essayez d'installer en mode de déploiement après avoir modifié votre fichier Gemfile" est resté affiché.
L’inspection de la sortie de travis-ci sur la console a révélé qu’une version plus ancienne de l’unité de traitement était utilisée.
Dans mon cas, j'ai dû modifier le fichier travis.yml pour ajouter:
before_install:
- gem update bundler
Cela a obligé travis-ci à utiliser la dernière version de bundler et à faire disparaître le message d'erreur.
Mon problème spécifique était lié à ce qui a été signalé par @JoshPinter, à savoir les divergences d'hôte dev-vs-deploy dans le protocole utilisé par le groupeur pour extraire les gems de github.
En résumé, tout ce que je devais faire était de modifier l'entrée Gemfile suivante ...
gem 'activeadmin', github: 'activeadmin'
... à cette syntaxe sécurisée ( voir référence ):
gem 'activeadmin', git: 'https://github.com/activeadmin/activeadmin.git'
Et mes déploiements sont revenus à la normale.
rm -fr .bundle
Correction du problème pour moi.
Dans notre cas, nous utilisions une fonctionnalité qui n'était pas disponible dans une ancienne version de bundler exécutée sur notre machine de production. Il suffisait donc de mettre à jour le bundler, c’est-à-dire de faire un gem update bundler.
Une autre cause de l'erreur:
C'est un peu idiot, mais je suis sûr que quelqu'un d'autre fera la même erreur.
Pour Rails 4, Heroku a ajouté le gem Rails_12factor. Si vous l'utilisiez avant de l'ajouter, vous aurez alors ces deux joyaux:
gem 'Rails_log_stdout', github: 'heroku/Rails_log_stdout'
gem 'Rails3_serve_static_assets', github: 'heroku/Rails3_serve_static_assets'
Vous devez les supprimer lorsque vous ajoutez le nouveau. (ils sont inclus). Je pense que vous pouvez vous en sortir jusqu'à ce que vous touchiez les lignes de votre fichier de gemme, puis Heroku remarquera la duplication et s'écria avec l'erreur ci-dessus.
bonne chance avec Rails 4.
Cette idée peut être dangereuse, mais si vous devez absolument tester quelque chose dans un environnement de déploiement en production, vous pouvez éditer le fichier .bundle/config.
# This value is normally '1'
# Set it to '0'
BUNDLE_FROZEN: '0'
Maintenant, appelez bundle, dans mon cas je devais mettre à jour un bijou spécifique, donc ceci ma commande
Rails_ENV=production bundle update <whatever gem>
Vous devriez probablement le modifier après la mise à jour, pour que tout fonctionne comme prévu, après. Encore une fois, ceci est probablement non pris en charge, et YMMV
Je suis tombé sur quelque chose de similaire avant. Une façon de résoudre ce problème, je pense, mais peut prendre plus d’espace sur votre serveur que vous le souhaitez, est de lancer
bundle install --deployment
et ensuite essayer de se déployer. Cela revient à installer toutes vos pierres précieuses dans le dossier du fournisseur, ce qui, à mon avis, est généralement bon à éviter ... mais qui fonctionnera probablement encore. Mon application se comportait ainsi, ma solution consistait à supprimer les versions exactes à télécharger dans mon Gemfile, puis à les regrouper et à les déployer.
gem 'Rails_admin', :git => 'git://github.com/sferik/Rails_admin.git', :branch => 'master'
à
gem 'Rails_admin'
Ou vous pouvez faire ce que cela suggère, et gérez votre projet hors du serveur de production sur une machine locale, regroupez-le, puis procédez au récurage sur votre serveur. Cette solution n'est peut-être pas correcte à 100%, mais une partie a fonctionné pour moi ... je pensais simplement que je partagerais. Bonne chance
J'ai lu une douzaine de solutions sur différentes ressources mais je n'ai pas trouvé exactement ce qui pourrait m'aider dans cette situation.
J'ai donc trouvé une solution. En disant exactement que j'ai lu le message d'erreur avec attention et qu'il y a eu une solution: Exécutez bundle install ailleurs . "Ailleurs" était mon Cloud9 où j'ai développé mon application. Donc mes pas
- copier Gemfile et Gemfile.lock du serveur sur la machine locale avec la commande
rsync - insérer ces deux fichiers dans mon projet RoR (j'ai utilisé Cloud9)
- ouvrez Gemfile et apportez les modifications que je souhaite. Dans mon cas, j'ai ajouté une gemme 'mince'
- dans le terminal cd de mon application sur Cloud9 et exécutez
bundle install. dans ce cas, vous aurez une modifiée version de Gemfile.lock - copier nouveau Gemfile et Gemfile.lock sur le serveur en utilisant
rsync - cd à mon dossier d'application et exécutez à nouveau
bundle install --deployment --without development testFAIT! Souhaite bonne chance à tous!
Après cette commande, vous pouvez réinstaller votre ensemble normal:
bundle install --no-deployment
Ce problème peut être lié aux sous-modules pointant vers d'anciennes versions de code. Pour moi, j'ai résolu ce problème en mettant à jour mes sous-modules
Si vous avez des sous-modules, essayez de lancer:
git submodule update --init
bundle install
J'ai eu le message d'erreur lors de la tentative de Push to Heroku. J'ai trouvé la solution suivante réparée.
- Git pull Origin master
- Statut git
- Git commit
- Maître Git Push Origin
- Git Push maître heroku
pour heroku, vous n'avez pas besoin de changer la syntaxe dans Gemfile. vous pouvez simplement ajouter BUNDLE_GITHUB__HTTPS (notez le double soulignement) en tant que variable d'environnement et le définir sur true (dans le tableau de bord de votre application heroku sous l'onglet Settings de la section Config Vars). cela fera passer le protocole de git:// à https:// pour toutes ces demandes.
J'ai rencontré un problème similaire, mais j'ai utilisé à la fois bundle install et bundle update et Heroku a toujours rejeté mon Push.
J'ai résolu le problème en supprimant simplement Gemfile.lock puis en exécutant à nouveau bundle install. J'ai ensuite ajouté, engagé et mis cela dans mon dépôt Git. Après cela, je n'ai eu aucun problème à pousser Heroku.
Je suis tombé sur le déploiement d'une application Nesta après quelques mises à jour de gemmes. Ce qui a fonctionné pour moi a été de supprimer le fichier Gemfile.lock , exécuter bundle install pour le générer à nouveau et le déployer à nouveau.