Can the runtime of a Heroku app know it's commit id?

Question

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?

Answer 1

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.