三种不同的选择,最好先...
SOURCE_VERSION
环境变量(构建时)
从 2015 年 4 月 1 日起,有一个SOURCE_VERSION
环境变量可用于在 Heroku 上运行的构建。对于 git-push 构建,这是正在构建的源的 git commit SHA-1:
https://devcenter.heroku.com/changelog-items/630
(感谢@srtech指出这一点!)
/etc/heroku/dyno
元数据文件(运行时)
Heroku have beta functionality to write out a /etc/heroku/dyno
metadata file onto your running dyno. If you email support you can probably get added to the beta. Here's a place where Heroku themselves are using it:
https://github.com/heroku/fix/blob/6c8ab7a/lib/heroku_dyno_metadata.rb
The contents look like this:
{
"dyno":{
"physical_id":"161bfad9-9e83-40b7-b385-78305db2f168",
"size":1,
"name":"run.7145"
},
"app":{
"id":null
},
"release":{
"id":50,
"commit":"2c3a0b24069af49b3de35b8e8c26765c1dba9ff0",
"description":null
}
}
..so release.commit
is the field you're after.
SBT-specific: use sbt-heroku
to build slug locally
My initial solution was to use the sbt-heroku
plugin published by Heroku themselves. This means no longer doing deploys by git push
(having the slug compiled on Heroku's own infrastructure), but instead compiling the slug locally and uploading that directly to Heroku. Because the slug is compiled locally, in my work repo, the Git information is all there and the build process can easily identify the commit id and embed it into the app's code.
The slug is substantially larger in size that a Git diff (90MB vs 0.5KB), but apart from that the solution works reasonably well. I'm actually using Travis to do continuous deployment, and so Travis was doing the sbt stage deployHeroku
for me (the Git commit id is available in that environment while building), meaning I could git-push from my laptop on the move, and Travis will do the large slug upload to Heroku.