Bundler: vous essayez d'installer en mode déploiement après avoir modifié votre Gemfile

Je suis assez nouveau dans bundler et capistrano, et j'essaye de les utiliser ensemble. Lorsque j'essaye de déployer, je reçois le message:

Vous essayez d'installer en mode déploiement après avoir modifié votre Gemfile. Exécutez `bundle install 'ailleurs et ajoutez le 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 arrive parce que j'ai lu dans la doc :

Si un Gemfile.lock existe et que vous avez mis à jour votre Gemfile (5), le bundler utilisera les dépendances dans Gemfile.lock pour toutes les gemmes que vous n'avez pas mises à jour, mais résoudra à nouveau les dépendances des gemmes que vous avez mises à jour . Vous pouvez trouver plus d'informations sur ce processus de mise à jour ci-dessous sous MISE À JOUR CONSERVATIVE.

J'interprète cela comme signifiant que le Bundler peut gérer le fait que mon Gemfile n'est pas ce à quoi il s'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 une machine Posix.

Edit: My Gemfile comprend des blocs logiques comme les suivants:

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

Le message d'erreur que vous obtenez en ce qui concerne Gemfile.lockpeut - être parce que votre Gemfileet Gemfile.lockne sont pas d' accord entre eux. Il semble que vous ayez changé quelque chose dans votre Gemfile depuis votre dernière exécution bundle install(ou update). Lorsque vous bundle install, il met à jour votre Gemfile.lock avec toutes les modifications que vous avez apportées à Gemfile.

Assurez-vous de l'exécuter bundle installlocalement et de vous enregistrer pour contrôler la source de votre nouvelle mise Gemfile.lockà jour par la suite. Ensuite, essayez de déployer.

Edit : Comme reconnu dans les commentaires, un conditionnel dans le Gemfile a abouti à un Gemfile.lock valide sur une plate-forme, invalide sur une autre. Fournir un indicateur : platform pour ces gemmes dépendant de la plate-forme dans le Gemfile devrait résoudre l'asymétrie.

vi .bundle / config

changer l'option BUNDLE_FROZEN de «1» à «0»

faire une "installation groupée"

OU

exécuter "bundle config"

voir si la valeur "gelée" est true, définissez-la sur false

bundle config gelé faux

Méfiez-vous de la configuration globale du Bundler.

J'avais une configuration globale sur mon environnement de développement en ce ~/.bundle/configque je n'avais pas dans mon environnement CI / Production qui faisait Gemfile.lockque le qui a été généré dans mon environnement de développement était différent de celui de mon environnement CI / Production.

Dans mon cas, je définissais la valeur github.httpstrue dans mon environnement de développement, mais je n'avais pas de configuration de ce type dans mon environnement CI / Production. Cela a rendu les deux Gemfile.lockfichiers différents.

Lorsque 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 avez des fichiers .gem obsolètes dans votre répertoire fournisseur / cache.

Peut-être que vous avez déjà couru $bundle install --deployment fichiers .gem «périmés» dans le cache?

Dans tous les cas, vous pouvez contourner cette erreur en exécutant: bundle install --no-deployment

C'est l'un des nombreux avantages de Rails ... les messages d'erreur vous indiquent souvent exactement ce qu'il faut faire pour résoudre le problème.

Mon problème spécifique était lié à ce que rapportait @JoshPinter, c'est-à-dire les écarts d'hôte dev-vs-deploy dans le protocole utilisé par le bundler pour récupérer les gemmes de github.

Pour faire une histoire courte, il me suffisait de modifier l' Gemfileentrée 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.

La solution pour moi était légèrement différente des autres énumérées ici. J'essayais de passer de sidekiq à sidekiq-pro (qui nécessite le bundler 1.7.12+), mais j'ai continué à recevoir le message "Vous essayez d'installer en mode déploiement après avoir changé votre Gemfile" de travis-ci

L'inspection de la sortie console de travis-ci a révélé qu'une ancienne version de bundler était utilisée.

Dans mon cas, j'ai dû éditer le fichier travis.yml pour ajouter:

before_install: - gem update bundler

Cela a forcé travis-ci à utiliser la dernière version de bundler et a fait disparaître le message d'erreur.

Je m'en fiche. C'est ce que j'ai fait. Il l'a corrigé.

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

rm -fr .bundle

Correction du problème pour moi.

J'ai déjà rencontré quelque chose de similaire. Une façon de résoudre ce problème, je pense, mais peut prendre plus d'espace sur votre serveur que vous ne le souhaitez, est d'exécuter

bundle install --deployment 

puis essayez de déployer. Cela fait quelque chose comme installer toutes vos gemmes dans le dossier du fournisseur, ce que je pense qu'il est généralement bon d'éviter ... mais fonctionnera probablement toujours. Mon application se comportait comme ceci, ma solution supprimait les versions exactes à télécharger dans mon Gemfile, puis le réassemblait et le déployait.

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

à

gem 'rails_admin'

Ou vous pouvez faire ce qu'il suggère, et transférer votre projet du serveur de production sur une machine locale, le regrouper, puis le repousser sur votre serveur. Cette solution n'est peut-être pas correcte à 100%, mais une partie a fonctionné pour moi ... je pensais juste partager. Bonne chance

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 ces deux gemmes:

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 tirer jusqu'à ce que vous touchiez les lignes de votre fichier gem, puis Heroku remarque la duplication et crie avec l'erreur ci-dessus.

bonne chance avec les rails 4.

Dans notre cas, nous utilisions une fonctionnalité qui n'était pas disponible dans une ancienne version de bundler qui fonctionnait sur notre machine de production. Il suffisait donc de mettre à jour le bundler, c'est-à-dire de faire un gem update bundler.

Cela peut être une idée dangereuse, mais si vous devez absolument tester quelque chose dans un environnement de déploiement de production, vous pouvez modifier le fichier .bundle / config

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

Maintenant, invoquez bundle, dans mon cas, je devais mettre à jour un gem spécifique, donc c'est ma commande

RAILS_ENV=production bundle update <whatever gem>

Vous devriez probablement le modifier après la mise à jour, pour que les choses fonctionnent comme prévu, par la suite. Encore une fois, cela n'est probablement pas pris en charge, et YMMV

J'ai rencontré ce déploiement d'une application Nesta après quelques mises à jour de gemmes. Ce qui a fonctionné pour moi était de supprimer le Gemfile.lock , de l'exécuter bundle installpour le régénérer et de le déployer à nouveau.

J'ai rencontré un problème similaire, mais j'ai fait les deux bundle installetbundle update et Heroku encore rejeté ma poussée.

J'ai résolu le problème en supprimant simplement Gemfile.lock, puis en le relançant bundle install. J'ai ensuite ajouté, validé et poussé cela dans mon repo git. Après cela, je n'ai eu aucun problème à pousser vers Heroku.

pour heroku, vous n'avez pas besoin de changer la syntaxe du Gemfile. vous pouvez simplement ajouter BUNDLE_GITHUB__HTTPS(notez le double tiret bas) en tant que variable d'environnement et le définir sur true(dans le tableau de bord de votre application heroku sous l' Settingsonglet de la Config Varssection). cela fera basculer le protocole de git://à https://pour toutes ces demandes.

J'ai eu le message d'erreur en essayant de pousser vers Heroku. J'ai trouvé la solution suivante corrigée.

1. Maître d'origine Git Pull
2. Statut Git
3. Git commit
4. Maître d'origine Git Push
5. Git push heroku master

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 d'exécuter:

git submodule update --init

bundle install

Après cette commande, vous pouvez recommencer l'installation de votre bundle normal:

bundle install --no-deployment

J'ai lu une dizaine de solutions sur différentes ressources mais je n'ai pas trouvé exactement ce qui pouvait m'aider dans cette situation

J'ai donc trouvé une solution. En disant exactement que j'ai lu attentivement le message d'erreur et qu'il y avait une solution: Exécutez l'installation du bundle ailleurs . «Ailleurs» était mon Cloud9 où j'ai développé mon application. Alors mes pas

1. copier Gemfile et Gemfile.lock du serveur vers la machine locale avec rsync commande
2. insérer ces deux fichiers dans mon projet RoR (j'ai utilisé Cloud9)
3. ouvrez Gemfile et apportez les modifications que je souhaite. Dans mon cas, j'ai ajouté un bijou `` mince ''
4. dans le terminal cd sur mon application sur Cloud9 et exécutez bundle install. dans ce cas, vous aurez une version modifiée de Gemfile.lock
5. copier le nouveau Gemfile et Gemfile.lock sur le serveur en utilisantrsync
6. cd dans le dossier de mon application et exécutez à nouveau bundle install --deployment --without development test FAIT! Je souhaite bonne chance à tous!