Geek Answers Handbook

Can the Heroku application run time know that it captures the identifier?

I would like the runtime of my Heroku app (Play / Scala running on Heroku cedars) to be able to tell me which git committed was built from. Heroku applications are usually created by the slug compiler on the Heroku framework - unfortunately, the slug compiler does this as an early part of this build process:

Delete unused files, including .git directories, .gitmodules files, everything in log and tmp, and everything listed at the top level of .slugignore.

... therefore git info is no longer available for the sbt-buildinfo that I use to write git commit.

How to write HEAD commit in slug? Is an environment variable with this information available?

+5
source share
2 answers

Three different options, best ...

SOURCE_VERSION environment variable (build time)

Starting April 1, 2015, the SOURCE_VERSION environment variable is available for assembly on Heroku. For git-push builds, this is the git commit SHA-1 of the source, which is being built:

https://devcenter.heroku.com/changelog-items/630

(thanks @srtech for pointing out that !)

/etc/heroku/dyno metadata file (runtime)

Heroku has beta functionality for writing the /etc/heroku/dyno metadata file to your dyno executable. If you support email support, you can probably add to the beta. Here is the place where Geroku uses it:

https://github.com/heroku/fix/blob/6c8ab7a/lib/heroku_dyno_metadata.rb

The content is as follows:

 { "dyno":{ "physical_id":"161bfad9-9e83-40b7-b385-78305db2f168", "size":1, "name":"run.7145" }, "app":{ "id":null }, "release":{ "id":50, "commit":"2c3a0b24069af49b3de35b8e8c26765c1dba9ff0", "description":null } }

.. therefore release.commit is the field you are in.

SBT specification: use sbt-heroku to create slug locally

My initial solution was to use the sbt-heroku published by Heroku themselves. This means that deployment is no longer performed using git push (with a pool compiled on Heroku's own infrastructure), but instead compiles slug locally and loading it directly into Heroku. Since slug is compiled locally, there is git information in my working repo, and the build process can easily identify the commit id and paste it into the application code.

The cork is significantly larger than git diff (90 MB vs 0.5 KB), but in addition, the solution works quite well. I actually use Travis for continuous deployment, and so Travis did sbt stage deployHeroku for me (the git commit identifier available in this environment when building), that is, I could git-push from my laptop on the go, and Travis will do a lot of slug loading in Heroku

+3
source

Run the validation filter (also known as "smudge") in your code and paste the HEAD SHA into the configuration file for your application.

0
source

More articles:


All Articles