Пакет: Ви намагаєтеся встановити в режимі розгортання після зміни вашого Gemfile

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

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

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

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

Я трактую це як таке, що Пакувальник може впоратися з тим, що мій 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

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

Переконайтесь, що ви запускаєте bundle installлокально, і після цього зареєструйтесь, щоб контролювати джерело нещодавно оновленого Gemfile.lock. Потім спробуйте розгорнути.

Редагувати : Як визнано в коментарях, умовна умова в Gemfile призвела до дійсного Gemfile.lock на одній платформі, недійсної на іншій. Надання прапора : platform для цих залежних від платформи дорогоцінних каменів у Gemfile має вирішити асиметрію.

vi .bundle / config

змінити опцію BUNDLE_FROZEN з "1" на "0"

зробити "встановити пакет"

АБО

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

подивіться, чи значення "заморожене" має значення true, встановіть його на false

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

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

У мене була глобальна конфігурація для мого середовища розробника, яка у ~/.bundle/configмене не була в моєму середовищі CI / Production, що спричинило б те, Gemfile.lockщо було створено у моєму середовищі розробника, іншим, ніж у моєму середовищі 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-файли у каталозі постачальника / кешу.

Можливо, ви раніше запускали програму, $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 використовувати останню версію пакета, і повідомлення про помилку зникло.

Мені все одно. Це те, що я зробив. Це виправлено.

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'

Або ви можете зробити те, що він пропонує, і Git ваш проект з робочого сервера на локальну машину, згрупувати його, а потім відштовхнути на ваш сервер. Це рішення може бути не на 100% правильним, але деякі з них працювали для мене ... просто думав, що поділюсь. Удачі

Ще одна причина помилки:

Це трохи нерозумно, але я впевнений, що хтось інший зробить ту ж помилку.

Для 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'

Ви повинні видалити їх, коли додаєте новий. (вони включені). Я думаю, вам вдасться уникнути цього, поки ви не торкнетеся цих рядків у вашому gem-файлі, тоді Heroku помітить дублювання та закричить із зазначеною вище помилкою.

удачі з Rails 4.

У нашому випадку ми використовували функцію, яка була недоступна у старій версії пакета, яка працювала на нашому виробничому комп'ютері. Тому було достатньо оновити пакет, тобто зробити a 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і Героку все одно відхилив мій поштовх.

Я вирішив проблему, просто видаливши Gemfile.lock, а потім запустивши bundle installзнову. Потім я додав, здійснив та підсунув це до свого git-репо. Після цього у мене не було проблем підштовхнутися до Героку.

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

У мене з’явилося повідомлення про помилку при спробі натиснути на Heroku. Я знайшов наступне рішення виправленим.

1. Майстер походження Git pull
2. Статус Git
3. Git коміт
4. Майстер походження Git push
5. Git push heroku master

Ця проблема може бути пов'язана з підмодулями, що вказують на старі версії коду. Для мене я вирішив це питання, оновивши свої підмодулі

Якщо у вас є підмодулі, спробуйте запустити:

git submodule update --init

bundle install

Після цієї команди ви можете знову встановити звичайний пакет:

bundle install --no-deployment

Я прочитав десяток рішень на різних ресурсах, але не знайшов, що саме могло б мені допомогти в цій ситуації

Тож я знайшов рішення. Точно кажучи, що я уважно прочитав повідомлення про помилку, і там було рішення: Запустити bundle install в іншому місці . "В іншому місці" був мій Cloud9, де я розробляв свій додаток. Тож мої кроки

1. скопіюйте Gemfile та Gemfile.lock з сервера на локальну машину за допомогою rsyncкоманди
2. вставити ці два файли в мій проект RoR (я використовував Cloud9)
3. відкрийте Gemfile і внесіть потрібні зміни. У моєму випадку я додав самоцвіт "тонкий"
4. у терміналі cd до мого додатка на Cloud9 та запустіть bundle install. у цьому випадку у вас буде змінена версія Gemfile.lock
5. скопіюйте нові Gemfile та Gemfile.lock на сервер за допомогоюrsync
6. cd до моєї папки програми та знову запустіть bundle install --deployment --without development test ГОТОВО! Побажайте ВСІХ удачі всім!