tre opzioni diverse, meglio prima ...
SOURCE_VERSION variabile d'ambiente (build-time)
Dal 1 ° aprile 2015, c'è una variabile di ambiente SOURCE_VERSION disposizione di build in esecuzione su Heroku. Per git-push costruisce, questo è il git commit SHA-1 della sorgente in corso di costruzione:
https://devcenter.heroku.com/changelog-items/630
(grazie a @srtech per pointing that out!)
/etc/heroku/dyno file di metadati (run -time)
Heroku hanno beta funzionalità per scrivere un file di metadati /etc/heroku/dyno sul vostro banco di prova in esecuzione. Se si invia un'e-mail all'assistenza, è probabile che tu possa essere aggiunto alla versione beta. Ecco un luogo dove Heroku stessi lo usano:
https://github.com/heroku/fix/blob/6c8ab7a/lib/heroku_dyno_metadata.rb
Il contenuto simile a questa:
{
"dyno":{
"physical_id":"161bfad9-9e83-40b7-b385-78305db2f168",
"size":1,
"name":"run.7145"
},
"app":{
"id":null
},
"release":{
"id":50,
"commit":"2c3a0b24069af49b3de35b8e8c26765c1dba9ff0",
"description":null
}
}
..quindi release.commit è il campo che stai cercando.
SBT-specifica: utilizzare sbt-heroku per costruire slug localmente
La mia soluzione iniziale era quello di utilizzare il plugin sbt-heroku pubblicato da Heroku stessi. Ciò significa che non è più necessario distribuire lo git push (con lo slug compilato sull'infrastruttura di Heroku), ma invece compilare lo slug localmente e caricarlo direttamente su Heroku. Poiché lo slug è compilato localmente, nel mio repository di lavoro, le informazioni Git sono tutte lì e il processo di compilazione può easily identify the commit id e lo incorporo nel codice dell'app.
Lo slug è di dimensioni notevolmente maggiori rispetto a un Git diff (90 MB contro 0,5 KB), ma a parte questo la soluzione funziona abbastanza bene. In realtà sto usando Travis per fare la distribuzione continua, e quindi Travis stava facendo il sbt stage deployHeroku per me (l'ID di commit Git è disponibile in quell'ambiente durante la costruzione), il che significa che potrei git-push dal mio portatile in movimento, e Travis carica il grande slug su Heroku.
È possibile inserire un hook post-checkout nel repository che registra l'ID da qualche parte non verrà cancellato. Per ottenerlo automaticamente quando cloni/init, inseriscilo nel tuo repository template. – jthill
@jthill Non sono sicuro di capire - gli hook sul lato client non vengono copiati quando si clona un repository, quindi come farebbero ad accedere al compilatore slug? http://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks#Client-Side-Hooks ... intendi qualcosa di particolare da 'template repo', oltre che essere il luogo in cui il il codice dell'app si trova? I modelli –
sono una caratteristica git, quando si esegue 'git init' o' git clone' git copia il contenuto iniziale da una directory di template. Il modello di default contiene esempi di hook, ad esempio. Quindi, qualunque processo stia creando quei repository che il compilatore di slug sta pulendo, sta anche facendo un checkout per i contenuti. Fai in modo che il template pronti contro termine che processa usi abbia il gancio checkout che desideri. – jthill