Heroku应用程序的运行时可以知道它是提交ID吗？ [英] Can the runtime of a Heroku app know it's commit id?
问题描述
我希望运行我的Heroku应用程序（Play / Scala，在Heroku Cedar上运行）能够向我报告哪个git提交它是从哪里构建的。 Heroku应用程序通常由Heroku的基础架构上的slug编译器构建 - 不幸的是，slug编译器会在构建过程的早期阶段执行 this ：
删除未使用的文件，包括.git目录，.gitmodules文件，
log和tmp中的任何内容以及顶级
.slugignore文件中指定的任何文件。
...所以Git信息不再提供给 sbt-buildinfo 插件我用来记录Git提交。
如何在slug中记录HEAD提交？是否有一个环境变量可用于此信息？
$ b
SOURCE_VERSION 环境变量（构建时间）
<从2015年4月1日起，有一个
SOURCE_VERSION 环境变量可用于构建在Heroku上运行。对于git-push构建，这是构建源的git commit SHA-1： changelog-items / 630rel =nofollow noreferrer> https://devcenter.heroku.com/changelog-items/630 （感谢@srtech的指出！）
/ etc / heroku / dyno 元数据文件（运行时）
< Heroku具有 beta 功能，可以将
/ etc / heroku / dyno 元数据文件写入您的运行dyno。如果你的电子邮件支持，你可能会被添加到测试版。这是Heroku自己使用它的地方： https://github.com/heroku/fix/blob/6c8ab7a/lib/heroku_dyno_metadata.rb
内容如下所示：
{
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 是您所在的字段。
特定SBT：使用 sbt-heroku 在本地构建slug
我最初的解决方案是使用 sbt-heroku git push （在Heroku自己的基础架构上编译slug）进行部署，而是直接在本地编译slug 并直接上传到Heroku。因为slug是在本地编译的，所以在我的工作回购中，Git信息都在那里，构建过程可以轻松识别提交ID并将其嵌入到应用程序的代码中。
块大小远远超过Git diff （90MB vs 0.5KB），但除此之外，该解决方案运行良好。我实际上是在使用Travis进行连续部署，因此Travis正在做 sbt stage deployHeroku 对于我来说（Git commit id在构建时可以在该环境中使用），这意味着我可以从我的笔记本电脑中进行git-push这个举动，特拉维斯将会把大块头上传到Heroku。
I'd like the runtime of my Heroku app (Play/Scala, running on Heroku Cedar) to be able to report to me which git commit it was built from. Heroku apps are generally built by the slug compiler on Heroku's infrastructure - unfortunately, the slug compiler does this as an early part of this build process:
Remove unused files, including .git directories, .gitmodules files, anything in log and tmp, and anything specified in a top-level .slugignore file.
...so the Git information is no longer available to the sbt-buildinfo plugin I'm using to record the Git commit.
How to record the HEAD commit in the slug? Is there an environment variable available with this information?
Three different options, best first...
SOURCE_VERSION environment variable (build-time)
From 1st April 2015, there's a SOURCE_VERSION environment variable available to builds running on Heroku. For git-push builds, this is the git commit SHA-1 of the source being built:
https://devcenter.heroku.com/changelog-items/630
(thanks to @srtech for pointing that out!)
/etc/heroku/dyno metadata file (run-time)
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.
这篇关于Heroku应用程序的运行时可以知道它是提交ID吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
