Bundler: вы пытаетесь установить в режиме развертывания после изменения вашего Gemfile

86

Я новичок в Bundler и Capistrano, и я пытаюсь использовать их вместе. Когда я пытаюсь развернуть, я получаю сообщение:

Вы пытаетесь установить в режиме развертывания после изменения вашего Gemfile. Запустите `bundle install 'в другом месте и добавьте обновленный Gemfile.lock в систему контроля версий.

Я не знаю, как удовлетворить систему, которая жалуется, и я не понимаю, почему возникает жалоба, потому что я прочитал в документе :

Если Gemfile.lock существует, и вы обновили свой Gemfile (5), сборщик будет использовать зависимости в Gemfile.lock для всех гемов, которые вы не обновляли, но повторно разрешит зависимости обновленных гемов. . Вы можете найти дополнительную информацию об этом процессе обновления ниже в разделе КОНСЕРВАТИВНОЕ ОБНОВЛЕНИЕ.

Я интерпретирую это как то, что Bundler может справиться с тем фактом, что мой Gemfile не такой, как ожидалось. Любая помощь?

Спецификации: Ruby 1.9.3, Rails 3.2.3, Capistrano 2.12.0, Bundler 1.1.4, Windows 7, развертывание на машине Posix.

Изменить: Мой Gemfile включает следующие логические блоки:

unless RbConfig::CONFIG['host_os'] === 'mingw32'
  # gem 'a' ...
end
JellicleCat
источник

Ответы:

80

Сообщение об ошибке, которое вы получаете, Gemfile.lockможет быть связано с тем, что вы Gemfileи Gemfile.lockне согласны друг с другом. Похоже, вы что-то изменили в своем Gemfile с момента последнего запуска bundle install(или update). Когда вы bundle install, он обновляет ваш Gemfile.lock любыми изменениями, внесенными вами в Gemfile.

Убедитесь, что вы запускаете bundle installлокально, и после этого зарегистрируйтесь для управления версиями вашего недавно обновленного Gemfile.lock. Затем попробуйте развернуть.

Изменить : как указано в комментариях, условие в Gemfile привело к действительному Gemfile.lock на одной платформе и недействительному на другой. Предоставление флага : platform для этих платформенно-зависимых гемов в Gemfile должно устранить асимметрию.

Эдд Морган
источник
2
Звучит как правильный ответ, но я выполнил установку пакета на своей машине разработчика, затем проверил как Gemfile, так и его блокировку в svn, а затем использовал capistrano. Может быть проблема , потому что Gemfile включает в себя блок с: unless RbConfig::CONFIG['host_os'] === 'mingw32'? (Следовательно, он должен объединять разные элементы на моем компьютере с Windows, чем на сервере Linux.)
JellicleCat
1
Вполне возможно. Проверьте содержимое вашего Gemfile.lock - содержит ли он ссылки на гем (ы), которые должны быть включены только в Windows? Если это так, это может означать, что на машине развертывания файлы Gemfile и Gemfile.lock отличаются. (Кроме того, я не эксперт по Bundler, но я почти уверен, что использование условных выражений в вашем Gemfile - не лучшая практика. Рассмотрите возможность использования групп или флага: platform ).
Эдд Морган
2
Использование :platformsфлага для драгоценных камней, которые нужны моему серверу prod (posix), но которых нет на моем сервере dev (win), имело значение: platforms :ruby do; gem 'mygem'; ...; end(Вы получите зеленый флажок, если не возражаете добавить эту инструкцию к своему ответу.)
JellicleCat
: платформа не может различать linux и / или darwin env с помощью :require, тоже хорошо работает stackoverflow.com/a/16475580/933358
Даниэль В. Кромптон
Это сработало для меня! Спасибо, спас меня от многих дней разочарования!
thenextmogul
26

vi. связка / config

измените параметр BUNDLE_FROZEN с «1» на «0»

сделать "пакетную установку"


ИЛИ

запустить "конфигурацию пакета"

проверить, истинно ли "замороженное" значение, установить значение false

конфигурация пакета заморожена false

Gaurav24
источник
Вот что сделало это для меня. Интересно, что в самом файле конфигурации ключ BUNDLE_FROZEN вообще не задан. Интересно, возможно ли, что я установил BUNDLE_FROZEN: 1 где-то еще?
Бо Г.
bundle config frozen falseэто мое исправление goto. Большое спасибо, прошло два года! Я считаю, что ответ Джошуа Пинтера касается комментария выше - это может быть глобальная конфигурация Bundler, влияющая на это.
SRack
bundle config frozen falseничего не сделал для меня. Применился к редактированию .bundle / config, в котором запись BUNDLE_FROZEN = "true" (текстовое значение true)
Артур
19

Следите за глобальной конфигурацией Bundler.

У меня была глобальная конфигурация в моей среде разработки, ~/.bundle/configкоторой у меня не было в моей среде CI / Production, что привело к тому, Gemfile.lockчто созданная в моей среде dev отличилась от той, что была в моей среде CI / Production.

В моем случае я установил github.httpsзначение true в моей среде разработки, но не имел такой конфигурации в моей среде CI / Production. Это привело к тому, что два Gemfile.lockфайла стали разными.

Джошуа Пинтер
источник
2
Благодарность! из всех простых ответов, связанных с этой нелепой ошибкой - это то, что вернуло меня к работе. Какого черта Heroku не помогает с этим автоматически? Какая глупая причина потерять последние 3 часа моей жизни!
hellion 02
2
Возможно, ты только что спас мне жизнь. Я готовился застрелиться из-за этого: P
Тайрон Уилсон
1
@JoshuaPinter, да, это меня спасло! хотя и потратил на это несколько часов ... но я пытался исправить предупреждения, которые получал при выполнении «установки пакета», и застрял в этом рассоле. Очень признателен!
daveomcd
1
@daveomcd Был там, рад, что сэкономил еще несколько часов, чтобы почесать голову. :)
Джошуа Пинтер
11

Когда вы видите следующее ...

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

... Тогда проблема, скорее всего, в том, что у вас есть устаревшие файлы .gem в каталоге vendor / cache.

Возможно, вы ранее запускали, $bundle install --deploymentчто помещало в кеш какие-то "устаревшие" файлы .gem?

В любом случае вы можете обойти эту ошибку, запустив: bundle install --no-deployment

Это одна из многих замечательных особенностей Rails ... сообщения об ошибках часто говорят вам, что именно делать, чтобы исправить проблему.

l3x
источник
7

Моя конкретная проблема была связана с тем, что сообщил @JoshPinter, то есть несоответствия хоста dev-vs-deploy в протоколе, используемом сборщиком для получения драгоценных камней из github.

Короче говоря, мне нужно было изменить следующую Gemfileзапись ...

gem 'activeadmin', github: 'activeadmin'

... к этому безопасному синтаксису ( см. ссылку ):

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

И мои развертывания вернулись в нормальное русло.

Джузеппе
источник
Это тоже устранило проблему для меня. Действительно странно.
Джошуа Мухейм
6

Решение для меня немного отличалось от других, перечисленных здесь. Я пытался перейти с sidekiq на sidekiq-pro (для которого требуется связка 1.7.12+), но продолжал получать сообщение «Вы пытаетесь установить в режиме развертывания после изменения вашего Gemfile» от travis-ci

Проверка вывода на консоль travis-ci показала, что использовалась более старая версия упаковщика.

В моем случае мне пришлось отредактировать файл travis.yml, чтобы добавить:

before_install: - gem update bundler

Это заставило travis-ci использовать последнюю версию связующего, и сообщение об ошибке исчезло.

Dacoinminster
источник
Это сработало для меня при Капистрано, чтобы запустить cap shellи gem update bundlerили with <role> gem update bundlerилиon <machine> gem update bundler
Эрик
4

Мне все равно. Это то, что я сделал. Он исправил это.

rm -rf .bundle 
rm -rf Gemfile.lock
bundle install
Уильям Энтрикен
источник
3
rm -fr .bundle

Исправил проблему для меня.

Анейл Маллаварапу
источник
1

Я раньше сталкивался с чем-то подобным. Я думаю, один из способов исправить это, но он может занять больше места на вашем сервере, чем вы хотите, - это запустить

bundle install --deployment 

а затем попробуйте развернуть. Это что-то вроде установки всех ваших драгоценных камней в папку поставщика, чего, я считаю, обычно лучше избегать ... но, вероятно, все равно будет работать. Раньше мое приложение вело себя так, моим решением было удаление точных версий для загрузки из моего Gemfile, а затем повторное объединение и развертывание.

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

к

gem 'rails_admin'

Или вы можете сделать то, что он предлагает, и перенести свой проект с рабочего сервера на локальный компьютер, связать его и затем повторно загрузить на свой сервер. Это решение может быть не на 100% правильным, но некоторые из них сработали для меня ... просто подумал, что поделюсь. Удачи

MoB
источник
1
--deploymentФлаг не делает разницы , если я не удалил Gemfile.lock. Так оно и должно быть?
JellicleCat
1

Другая причина ошибки:

Это немного глупо, но я уверен, что кто-то другой совершит ту же ошибку.

Для Rails 4 Heroku добавил драгоценный камень rails_12factor. Если вы использовали его до того, как его добавили, то у вас будут два драгоценных камня:

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

Вы должны удалить их, когда добавляете новый. (они включены). Я думаю, вам это сойдет с рук, пока вы не коснетесь этих строк в своем файле драгоценного камня, тогда Heroku заметит дублирование и выдаст ошибку, указанную выше.

удачи с Rails 4.

бобдельсол
источник
1

В нашем случае мы использовали функцию, которой не было в старой версии связующего, которая работала на нашей производственной машине. Поэтому было достаточно обновить бандлер, т.е. сделать gem update bundler.

ботаник
источник
Спасибо - у меня тоже была эта проблема. Оказалось, что версия сборщика на сервере была старше той, которую мы использовали на наших рабочих столах.
Натан Бертрам
1

Это может быть опасной идеей, но если абсолютно необходимо что-то протестировать в производственной среде развертывания, вы можете отредактировать файл .bundle / config.

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

Теперь вызовите пакет, в моем случае мне нужно было обновить конкретный драгоценный камень, поэтому эта моя команда

RAILS_ENV=production bundle update <whatever gem>

Вероятно, вам следует изменить его после обновления, чтобы впоследствии все работало так, как вы ожидаете. Опять же, это, вероятно, не поддерживается, и YMMV

Чубаркла
источник
0

Я столкнулся с этим при развертывании приложения Nesta после некоторых обновлений драгоценных камней. У меня сработало удаление Gemfile.lock , запуск bundle installдля его повторной генерации и повторное развертывание.

Ярин
источник
0

Я столкнулся с аналогичной проблемой, но я сделал и то, bundle installи другое, bundle updateи Heroku все равно отклонил мой толчок.

Я решил проблему, просто удалив Gemfile.lock и запустив bundle installснова. Затем я добавил, зафиксировал и отправил это в свой репозиторий git. После этого у меня не было проблем с переходом на Heroku.

Райан Рич
источник
Если вы не исправили версии гемов в своем гемфайле, это рискованно ... это может привести к обновлению гемов и поломке вашего приложения
Абрам
0

для heroku вам не нужно менять синтаксис в Gemfile. вы можете просто добавить BUNDLE_GITHUB__HTTPS(обратите внимание на двойное подчеркивание) в качестве переменной среды и установить для нее значение true(на панели инструментов вашего приложения heroku под Settingsвкладкой в Config Varsразделе). это переключит протокол с git://на https://для всех таких запросов.

ясность
источник
0

У меня было сообщение об ошибке при попытке отправить в Heroku. Я нашел следующее исправленное решение.

  1. Git pull origin master
  2. Статус Git
  3. Git commit
  4. Git push origin master
  5. Мастер Git push heroku
Бен Страчан
источник
0

Эта проблема может быть связана с подмодулями, указывающими на старые версии кода. Для меня я решил эту проблему, обновив свои подмодули.

Если у вас есть подмодули, попробуйте запустить:

git submodule update --init

bundle install

Джерард Симпсон
источник
0

После этой команды вы можете снова выполнить обычную установку пакета:

bundle install --no-deployment
ServerElf
источник
0

Прочитал с десяток решений на разных ресурсах, но не нашел, что именно могло мне помочь в этой ситуации

Так что я нашел решение. Точно говоря, я внимательно прочитал сообщение об ошибке, и было решение: запустить установку пакета в другом месте . «В другом месте» был мой Cloud9, где я разработал свое приложение. Итак, мои шаги

  1. скопируйте Gemfile и Gemfile.lock с сервера на локальный компьютер с помощью rsyncкоманды
  2. вставьте эти два файла в мой проект RoR (я использовал Cloud9)
  3. откройте Gemfile и внесите нужные мне изменения. В моем случае я добавил драгоценный камень 'тонкий'
  4. в терминальном компакт-диске в мое приложение на Cloud9 и запустите bundle install . в этом случае у вас будет измененная версия Gemfile.lock
  5. копировать новые Gemfile и Gemfile.lock на сервер, используяrsync
  6. cd в папку с моим приложением и снова запустите bundle install --deployment --without development test DONE! Желаю удачи всем!
Виталий ЛиБрус
источник