Bundler: stai tentando di eseguire l'installazione in modalità di distribuzione dopo aver modificato il tuo Gemfile

Sono abbastanza nuovo per bundler e capistrano e sto cercando di usarli insieme. Quando provo a eseguire la distribuzione, ricevo il messaggio:

Stai tentando di eseguire l'installazione in modalità di distribuzione dopo aver modificato Gemfile. Esegui "bundle install" altrove e aggiungi il Gemfile.lock aggiornato al controllo della versione.

Non so come soddisfare il sistema che si lamenta e non capisco perché il reclamo sta arrivando perché ho letto nel documento :

Se esiste un Gemfile.lock e hai aggiornato Gemfile (5), il bundler utilizzerà le dipendenze nel Gemfile.lock per tutte le gemme che non hai aggiornato, ma risolverà nuovamente le dipendenze delle gemme che hai aggiornato . Puoi trovare ulteriori informazioni su questo processo di aggiornamento di seguito in AGGIORNAMENTO CONSERVATIVO.

Lo interpreto nel senso che Bundler può gestire il fatto che il mio Gemfile non è quello che si aspettava. Qualsiasi aiuto?

Specifiche: Ruby 1.9.3, Rails 3.2.3, Capistrano 2.12.0, Bundler 1.1.4, Windows 7, distribuzione su una macchina Posix.

Modifica: il mio Gemfile include blocchi logici come i seguenti:

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

Il messaggio di errore che stai ricevendo Gemfile.lockpotrebbe essere perché il tuo Gemfilee Gemfile.locknon sono d'accordo tra loro. Sembra che tu abbia cambiato qualcosa nel tuo Gemfile dall'ultima volta che hai eseguito bundle install(o update). Quando tu bundle install, aggiorna il tuo Gemfile.lock con tutte le modifiche apportate a Gemfile.

Assicurati di eseguire bundle installlocalmente e di eseguire il check-in per il controllo del codice sorgente appena aggiornato Gemfile.lock. Quindi prova a distribuire.

Modifica : come riconosciuto nei commenti, un condizionale nel Gemfile ha generato un Gemfile.lock valido su una piattaforma, non valido su un'altra. Fornire un flag : platform per queste gemme dipendenti dalla piattaforma nel Gemfile dovrebbe risolvere l'asimmetria.

vi .bundle / config

cambia l'opzione BUNDLE_FROZEN da "1" a "0"

fare "installazione in bundle"

O

esegui "bundle config"

controlla se il valore "congelato" è vero impostalo su falso

configurazione bundle congelata false

Fai attenzione alla configurazione globale di Bundler.

Avevo una configurazione globale sul mio ambiente di sviluppo in ~/.bundle/configquanto non avevo nel mio ambiente CI / produzione che ha causato ilGemfile.lock che il file generato nel mio ambiente di sviluppo fosse diverso da quello nel mio ambiente CI / produzione.

Nel mio caso stavo impostando github.httpssu true nel mio ambiente di sviluppo ma non avevo tale configurazione nel mio ambiente CI / Produzione. Ciò ha causato la Gemfile.lockdifferenza tra i due file.

Quando vedi quanto segue ...

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

... Quindi, il problema è molto probabile che tu abbia file .gem obsoleti nella tua directory vendor / cache.

Forse hai già corso $bundle install --deployment che ha messo alcuni file .gem "obsoleti" nella cache?

In ogni caso, puoi superare questo errore eseguendo: bundle install --no-deployment

Questa è una delle tante grandi cose di Rails ... i messaggi di errore spesso ti dicono esattamente cosa fare per risolvere il problema.

Il mio problema specifico era correlato a quanto riportato da @JoshPinter, ovvero discrepanze host dev-vs-deploy nel protocollo utilizzato dal bundler per recuperare le gemme da github.

Per farla breve, tutto quello che dovevo era modificare la seguente Gemfilevoce ...

gem 'activeadmin', github: 'activeadmin'

... a questa sintassi sicura ( vedi riferimento ):

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

E le mie distribuzioni sono tornate alla normalità.

La soluzione per me era leggermente diversa dalle altre elencate qui. Stavo cercando di aggiornare da sidekiq a sidekiq-pro (che richiede il bundler 1.7.12+), ma continuavo a ricevere il messaggio "Stai tentando di installare in modalità di distribuzione dopo aver cambiato il tuo Gemfile" da travis-ci

L'ispezione dell'output della console di travis-ci ha rivelato che era in uso una versione precedente di bundler.

Nel mio caso, ho dovuto modificare il file travis.yml per aggiungere:

before_install: - gem update bundler

Ciò ha costretto travis-ci a utilizzare l'ultima versione del bundler e ha eliminato il messaggio di errore.

Non mi interessa Questo è quello che ho fatto. L'ha risolto.

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

rm -fr .bundle

Risolto il problema per me.

Un'altra causa dell'errore:

Questo è un po 'sciocco, ma sono sicuro che qualcun altro farà lo stesso errore.

Per Rails 4 Heroku ha aggiunto la gemma rails_12factor. Se lo stavi usando prima che lo aggiungessero, allora avrai queste due gemme:

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

Devi rimuoverli quando aggiungi quello nuovo. (sono inclusi). Penso che tu possa farla franca finché non tocchi le linee nel tuo file gem, quindi Heroku nota la duplicazione e grida con l'errore di cui sopra.

buona fortuna con Rails 4.

Mi sono imbattuto in qualcosa di simile prima. Un modo per risolverlo, penso, ma potrebbe richiedere più spazio sul tuo server di quanto desideri, è eseguire

bundle install --deployment 

e quindi provare a distribuire. Questo fa qualcosa come installare tutte le tue gemme nella cartella del fornitore, che credo sia generalmente buono da evitare ... ma probabilmente funzionerà ancora. La mia app si comportava in questo modo, la mia soluzione era rimuovere le versioni esatte da scaricare dal mio Gemfile, quindi riassemblare e distribuire.

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

per

gem 'rails_admin'

Oppure puoi fare ciò che suggerisce e trasferire il tuo progetto dal server di produzione su una macchina locale, raggrupparlo e quindi reinserirlo sul tuo server. Questa soluzione potrebbe non essere corretta al 100% ma alcuni di essi hanno funzionato per me ... ho solo pensato di condividerlo. In bocca al lupo

Nel nostro caso stavamo utilizzando una funzionalità che non era disponibile in una vecchia versione di bundler che girava sulla nostra macchina di produzione. Quindi è stato sufficiente aggiornare il bundler, ovvero fare un file gem update bundler.

Questa potrebbe essere un'idea pericolosa, ma se è assolutamente necessario testare qualcosa in un ambiente di distribuzione di produzione, è possibile modificare il file .bundle / config

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

Ora invoca bundle, nel mio caso avevo bisogno di aggiornare una gemma specifica, quindi questo è il mio comando

RAILS_ENV=production bundle update <whatever gem>

Probabilmente dovresti cambiarlo di nuovo dopo l'aggiornamento, quindi le cose funzioneranno come ti aspetti, in seguito. Di nuovo, questo probabilmente non è supportato e YMMV

Mi sono imbattuto in questo distribuendo un'app Nesta dopo alcuni aggiornamenti di gemme. Ciò che ha funzionato per me è stato eliminare Gemfile.lock , eseguire bundle installper rigenerarlo e distribuirlo di nuovo.

Ho riscontrato un problema simile, tuttavia ho fatto sia bundle installebundle update e Heroku ancora respinto la mia spinta.

Ho risolto il problema eliminando Gemfile.lock e quindi eseguendo di bundle installnuovo. Ho quindi aggiunto, eseguito il commit e inviato il messaggio al mio repository git. Dopo di che non ho avuto problemi a spingere verso Heroku.

per heroku, non è necessario modificare la sintassi nel file Gemfile. puoi semplicemente aggiungere BUNDLE_GITHUB__HTTPS(nota il doppio trattino basso) come variabile d'ambiente e impostarla su true(nella dashboard della tua app heroku sotto la Settingsscheda nella Config Varssezione). questo cambierà il protocollo da git://a https://per tutte queste richieste.

Ho ricevuto il messaggio di errore durante il tentativo di invio a Heroku. Ho trovato la seguente soluzione corretta.

1. Git pull origin master
2. Stato Git
3. Git commit
4. Git push origin master
5. Git spinge heroku master

Questo problema può essere correlato ai sottomoduli che puntano a vecchie versioni di codice. Per me, ho risolto questo problema aggiornando i miei sottomoduli

Se hai sottomoduli, prova a eseguire:

git submodule update --init

bundle install

Dopo questo comando, puoi eseguire di nuovo la normale installazione del bundle:

bundle install --no-deployment

Ho letto una dozzina di soluzioni su diverse risorse ma non ho trovato esattamente cosa potesse aiutarmi in questa situazione

Quindi ho trovato una soluzione. Esattamente dicendo che ho letto attentamente il messaggio di errore e c'era una soluzione: eseguire l'installazione del pacchetto altrove . "Altrove" era il mio Cloud9 dove ho sviluppato la mia app. Quindi i miei passi

1. copia Gemfile e Gemfile.lock dal server alla macchina locale con il rsynccomando
2. inserisci questi due file nel mio progetto RoR (ho usato Cloud9)
3. apri Gemfile e apporta le modifiche desiderate. Nel mio caso ho aggiunto gemma 'sottile'
4. nel terminale cd alla mia app su Cloud9 ed esegui bundle install. in questo caso avrai una versione modificata di Gemfile.lock
5. copia i nuovi Gemfile e Gemfile.lock sul server utilizzandorsync
6. cd nella cartella della mia app e di nuovo esegui bundle install --deployment --without development test FATTO! Auguro buona fortuna a tutti!