2014-12-12 11 views
6

È possibile ottenere una chiave univoca per lumaca/rilascio da un banco di prova in esecuzione? Stavo seguendo questo article per impostare RAILS_CACHE_ID (per scadenza etags dopo schieramenti), ma ha scoperto che la dynos nave non è più con GIT configurato (che causa questo errore):Ottieni versione/codice codice Heroku da Dyno in esecuzione

fatal: Not a git repository (or any parent up to mount point /app) 
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). 

Ho anche considerato l'impostazione in una config/initializers al Ora corrente ma ovviamente non funzionerebbe su più dynos. Qualche idea?

risposta

9

C'è un nuovo (Nov 2015) laboratori caratteristica che fa proprio quello che serve "Dyno metadati" https://devcenter.heroku.com/changelog-items/768

heroku labs:enable runtime-dyno-metadata -a <app name> 

Poi Heroku:

~ $ env 
HEROKU_APP_ID:     9daa2797-e49b-4624-932f-ec3f9688e3da 
HEROKU_APP_NAME:     example-app 
HEROKU_DYNO_ID:     1vac4117-c29f-4312-521e-ba4d8638c1ac 
HEROKU_RELEASE_VERSION:   v42 
HEROKU_SLUG_COMMIT:    2c3a0b24069af49b3de35b8e8c26765c1dba9ff0 
HEROKU_SLUG_DESCRIPTION:   Deploy 2c3a0b2 
+0

Dopo aver abilitato il dyno-metadata, ho aggiunto questa riga a 'config/application.rb':' ENV ['RAILS_CACHE_ID'] = ENV ['HEROKU_RELEASE_VERSION'] 'così quando l'app si avvia imposta l'ID della cache sulla versione di Heroku versione. Ciò significa anche che utilizzerà un nuovo ID cache quando si modificano le variabili env, ma non è necessariamente una cosa negativa. – Josh

0

Una soluzione consiste nell'utilizzare un gancio di pre-push git per impostare un valore di configurazione di heroku. Dal momento che è fatto prima della compilazione push e slug, la variabile di configurazione sarà disponibile come var ENV per l'app.

.git/hooks/pre-push:

#!/bin/sh 

remote="$1" 
url="$2" 
while read local_ref local_sha remote_ref remote_sha 
do 
    if [[ $url =~ heroku ]] ; then 
    app=$(git remote show -n $remote | sed -n -E -e 's/[[:space:]]+(Push[[:space:]]+URL)(\/|:).+(:|\/)(.*)\.git$/\4/gp') 
    echo Setting RAILS_CACHE_ID to $local_sha on app $app 
    heroku config:set RAILS_CACHE_ID=$local_sha --app $app 
    fi 
done 
exit 0 

Il file pre-push.sample ha alcuni documenti sui parametri che il gancio è chiamato con. Sto usando l'output dettagliato di git remote per determinare su quale app impostare il valore di configurazione. L'opzione '-E' per sed è per Mac OS X - se stai usando GNU sed sostituiscilo con '-r'.

Un'altra soluzione è utilizzare heroku-api tramite uno script profile.d per ottenere l'id di rilascio univoco. Questo esempio usa curl per ottenere l'ultimo id di rilascio usando l'intestazione RANGE. Non è il riferimento di commit, ma sarà unico per ogni versione, compresi i rollback e le modifiche di configurazione. Dovrai impostare API_KEY e APP_NAME come variabili di configurazione di heroku.

.profile.d/release.sh

# get release id and set as RAILS_CACHE_ID 

# Heroku config variables that need to be set 
# API_KEY: heroku api key (get from dashboard or `heroku auth:token` 
# APP_NAME: set this to your app_name (this could be hardcoded in the profile.d script but 
#   would make it harder to manage apps with multiple environments 

res=$(curl -s -H "Accept: application/vnd.heroku+json; version=3"\ 
       -H "Authorization: Bearer $API_KEY"\ 
       -H "Range: version ..; order=desc, max=1"\ 
       -X GET https://api.heroku.com/apps/$APP_NAME/releases) 
release_id=$(ruby -rjson -e "j = JSON.parse('$res'); puts j[0]['id']") 

export RAILS_CACHE_ID=$release_id 

Nell'applicazione rotaie, ENV [ 'RAILS_CACHE_ID'] dovrebbero ora essere impostato il più recente id rilascio. Si potrebbe anche usare questa stessa strategia in un inizializzatore di rotaie.

+0

Grazie questo tipo di opere, ma non lo farà supporto roll-backs/roll-forward –

+0

Sì, questa è una limitazione piuttosto importante che non ho considerato. Vedere la risposta aggiornata per una versione .profile.d –

+0

Grazie per l'aggiornamento. Immagino che l'unica limitazione qui è che se l'API non riesce mai a rispondere, è necessario che la logica venga ripetuta. Spero che Heroku aggiunga un modo più semplice per farlo in futuro. –

Problemi correlati