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


86

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

Réponses:


80

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.


2
Cela semble être la bonne réponse, mais j'ai exécuté l'installation du bundle sur ma machine de développement, puis vérifié à la fois le Gemfile et son verrou dans svn, puis utilisé capistrano. Le problème pourrait être parce que le Gemfile comprend un bloc avec: unless RbConfig::CONFIG['host_os'] === 'mingw32'? (Ergo, il devrait regrouper des éléments différents sur mon ordinateur Windows que sur le serveur Linux.)
JellicleCat

1
Très probablement. Vérifiez le contenu de votre Gemfile.lock - contient-il des références gem (s) qui ne devraient être incluses que sur Windows? Si tel est le cas, cela suggère que sur la machine de déploiement, Gemfile et Gemfile.lock diffèrent. (De plus, je ne suis pas un expert en Bundler, mais je suis sûr que mettre des conditions dans votre Gemfile n'est pas la meilleure pratique. Pensez à utiliser des groupes ou l' indicateur: platform ).
Edd Morgan

2
Utiliser le :platformsdrapeau pour les gemmes dont mon serveur prod (posix) avait besoin mais qui n'étaient pas sur mon serveur dev (win) a fait la différence: platforms :ruby do; gem 'mygem'; ...; end(Vous obtenez la coche verte si cela ne vous dérange pas d'ajouter cette instruction à votre réponse.)
JellicleCat

: la plate-forme n'est pas capable de faire la distinction entre linux et / ou darwin env en utilisant :require, fonctionne bien aussi stackoverflow.com/a/16475580/933358
Daniël W. Crompton

Cela a fonctionné pour moi! Merci, m'a sauvé de plus de jours de frustration!
thenextmogul

26

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


C'est ce qui a fait ça pour moi. Fait intéressant, dans le fichier de configuration lui-même, la clé BUNDLE_FROZEN n'a pas été définie du tout. Je me demande, est-il possible que j'aie mis BUNDLE_FROZEN: 1 ailleurs?
Bo G.

bundle config frozen falseest ma solution goto. Merci beaucoup, deux ans plus tard! Je crois que la réponse de Joshua Pinter répond au commentaire ci-dessus - cela peut être la configuration globale du Bundler qui a un impact sur cela.
SRack

bundle config frozen falsen'a rien fait pour moi. Recouru à l'édition .bundle / config dans lequel l'entrée BUNDLE_FROZEN = "true" (textual true)
Arthur

19

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.


2
Merci! de toutes les réponses simples qui volent autour de cette erreur ridicule - c'est ce qui m'a fait retourner au travail. Pourquoi diable Heroku n'assiste-t-il pas automatiquement avec ça? Quelle mauvaise raison d'avoir perdu les 3 dernières heures de ma vie!
hellion

2
Vous avez peut-être juste sauvé ma vie. Je m'apprêtais à me tirer dessus: P
Tyrone Wilson

1
@JoshuaPinter, oui cela m'a sauvé! bien que j'aie passé plusieurs heures dessus ... mais j'essayais de corriger les avertissements que je recevais en faisant 'l'installation du bundle' et je suis resté coincé dans ce cornichon. Très appréciée!
daveomcd

1
@daveomcd J'y suis allé, heureux que cela vous ait épargné encore plusieurs heures de vous gratter la tête. :)
Joshua Pinter

11

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.


7

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.


Cela a aussi résolu le problème pour moi. Vraiment étrange.
Joshua Muheim

6

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.


Cela a fonctionné pour moi sous Capistrano pour courir cap shellet gem update bundlerou with <role> gem update bundlerouon <machine> gem update bundler
Eric

4

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

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


1

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


1
Le --deploymentdrapeau n'a pas fait de différence à moins que je supprime le Gemfile.lock. Est-ce que c'est censé être ainsi?
JellicleCat

1

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.


1

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.


Merci - J'ai eu ce problème aussi. Il s'est avéré que la version du bundler sur le serveur était plus ancienne que celle que nous utilisions sur nos bureaux.
Nathan Bertram

1

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


0

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.


0

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.


À moins que vous n'ayez corrigé vos versions de gemmes dans votre fichier de gemmes, c'est risqué. Cela pourrait mettre à jour les gemmes et casser votre application
Abram

0

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.


0

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

0

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


0

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

bundle install --no-deployment

0

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!
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.