Я новичок в 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
источник
unless RbConfig::CONFIG['host_os'] === 'mingw32'
? (Следовательно, он должен объединять разные элементы на моем компьютере с Windows, чем на сервере Linux.):platforms
флага для драгоценных камней, которые нужны моему серверу prod (posix), но которых нет на моем сервере dev (win), имело значение:platforms :ruby do; gem 'mygem'; ...; end
(Вы получите зеленый флажок, если не возражаете добавить эту инструкцию к своему ответу.):require
, тоже хорошо работает stackoverflow.com/a/16475580/933358vi. связка / config
измените параметр BUNDLE_FROZEN с «1» на «0»
сделать "пакетную установку"
ИЛИ
запустить "конфигурацию пакета"
проверить, истинно ли "замороженное" значение, установить значение false
конфигурация пакета заморожена false
источник
bundle config frozen false
это мое исправление goto. Большое спасибо, прошло два года! Я считаю, что ответ Джошуа Пинтера касается комментария выше - это может быть глобальная конфигурация Bundler, влияющая на это.bundle config frozen false
ничего не сделал для меня. Применился к редактированию .bundle / config, в котором запись BUNDLE_FROZEN = "true" (текстовое значение true)Следите за глобальной конфигурацией Bundler.
У меня была глобальная конфигурация в моей среде разработки,
~/.bundle/config
которой у меня не было в моей среде CI / Production, что привело к тому,Gemfile.lock
что созданная в моей среде dev отличилась от той, что была в моей среде CI / Production.В моем случае я установил
github.https
значение true в моей среде разработки, но не имел такой конфигурации в моей среде CI / Production. Это привело к тому, что дваGemfile.lock
файла стали разными.источник
Когда вы видите следующее ...
$ 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 ... сообщения об ошибках часто говорят вам, что именно делать, чтобы исправить проблему.
источник
Моя конкретная проблема была связана с тем, что сообщил @JoshPinter, то есть несоответствия хоста dev-vs-deploy в протоколе, используемом сборщиком для получения драгоценных камней из github.
Короче говоря, мне нужно было изменить следующую
Gemfile
запись ...gem 'activeadmin', github: 'activeadmin'
... к этому безопасному синтаксису ( см. ссылку ):
gem 'activeadmin', git: 'https://github.com/activeadmin/activeadmin.git'
И мои развертывания вернулись в нормальное русло.
источник
Решение для меня немного отличалось от других, перечисленных здесь. Я пытался перейти с sidekiq на sidekiq-pro (для которого требуется связка 1.7.12+), но продолжал получать сообщение «Вы пытаетесь установить в режиме развертывания после изменения вашего Gemfile» от travis-ci
Проверка вывода на консоль travis-ci показала, что использовалась более старая версия упаковщика.
В моем случае мне пришлось отредактировать файл travis.yml, чтобы добавить:
before_install: - gem update bundler
Это заставило travis-ci использовать последнюю версию связующего, и сообщение об ошибке исчезло.
источник
cap shell
иgem update bundler
илиwith <role> gem update bundler
илиon <machine> gem update bundler
Мне все равно. Это то, что я сделал. Он исправил это.
rm -rf .bundle rm -rf Gemfile.lock bundle install
источник
rm -fr .bundle
Исправил проблему для меня.
источник
Я раньше сталкивался с чем-то подобным. Я думаю, один из способов исправить это, но он может занять больше места на вашем сервере, чем вы хотите, - это запустить
bundle install --deployment
а затем попробуйте развернуть. Это что-то вроде установки всех ваших драгоценных камней в папку поставщика, чего, я считаю, обычно лучше избегать ... но, вероятно, все равно будет работать. Раньше мое приложение вело себя так, моим решением было удаление точных версий для загрузки из моего Gemfile, а затем повторное объединение и развертывание.
gem 'rails_admin', :git => 'git://github.com/sferik/rails_admin.git', :branch => 'master'
к
gem 'rails_admin'
Или вы можете сделать то, что он предлагает, и перенести свой проект с рабочего сервера на локальный компьютер, связать его и затем повторно загрузить на свой сервер. Это решение может быть не на 100% правильным, но некоторые из них сработали для меня ... просто подумал, что поделюсь. Удачи
источник
--deployment
Флаг не делает разницы , если я не удалил Gemfile.lock. Так оно и должно быть?Другая причина ошибки:
Это немного глупо, но я уверен, что кто-то другой совершит ту же ошибку.
Для 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.
источник
В нашем случае мы использовали функцию, которой не было в старой версии связующего, которая работала на нашей производственной машине. Поэтому было достаточно обновить бандлер, т.е. сделать
gem update bundler
.источник
Это может быть опасной идеей, но если абсолютно необходимо что-то протестировать в производственной среде развертывания, вы можете отредактировать файл .bundle / config.
# This value is normally '1' # Set it to '0' BUNDLE_FROZEN: '0'
Теперь вызовите пакет, в моем случае мне нужно было обновить конкретный драгоценный камень, поэтому эта моя команда
RAILS_ENV=production bundle update <whatever gem>
Вероятно, вам следует изменить его после обновления, чтобы впоследствии все работало так, как вы ожидаете. Опять же, это, вероятно, не поддерживается, и YMMV
источник
Я столкнулся с этим при развертывании приложения Nesta после некоторых обновлений драгоценных камней. У меня сработало удаление Gemfile.lock , запуск
bundle install
для его повторной генерации и повторное развертывание.источник
Я столкнулся с аналогичной проблемой, но я сделал и то,
bundle install
и другое,bundle update
и Heroku все равно отклонил мой толчок.Я решил проблему, просто удалив Gemfile.lock и запустив
bundle install
снова. Затем я добавил, зафиксировал и отправил это в свой репозиторий git. После этого у меня не было проблем с переходом на Heroku.источник
для heroku вам не нужно менять синтаксис в
Gemfile
. вы можете просто добавитьBUNDLE_GITHUB__HTTPS
(обратите внимание на двойное подчеркивание) в качестве переменной среды и установить для нее значениеtrue
(на панели инструментов вашего приложения heroku подSettings
вкладкой вConfig Vars
разделе). это переключит протокол сgit://
наhttps://
для всех таких запросов.источник
У меня было сообщение об ошибке при попытке отправить в Heroku. Я нашел следующее исправленное решение.
источник
Эта проблема может быть связана с подмодулями, указывающими на старые версии кода. Для меня я решил эту проблему, обновив свои подмодули.
Если у вас есть подмодули, попробуйте запустить:
git submodule update --init
bundle install
источник
После этой команды вы можете снова выполнить обычную установку пакета:
bundle install --no-deployment
источник
Прочитал с десяток решений на разных ресурсах, но не нашел, что именно могло мне помочь в этой ситуации
Так что я нашел решение. Точно говоря, я внимательно прочитал сообщение об ошибке, и было решение: запустить установку пакета в другом месте . «В другом месте» был мой Cloud9, где я разработал свое приложение. Итак, мои шаги
rsync
командыbundle install
. в этом случае у вас будет измененная версия Gemfile.lockrsync
bundle install --deployment --without development test
DONE! Желаю удачи всем!источник