STACK env in buildpack api & portable buildpacks

[Guillaume Berche]

Heroku buildpack API exposes the STACK environment variable and suggests into [1] that buildpack maintainers should inspect this variable to fetch binaries associated with the requested stacks, or handle differences in stack content [4]. Looking at both CF docs [2] and checking on run.pivotal.io I don't see a similar STACK env variable being defined which could ease heroku buildpack portability or support a future stack beyond lucid64 (centos or trusty ?)

Any plans around this ? Searching in trackers I could only find one somewhat related in diego [3] for multi stack support but not mention of the STACK env var

Thanks in advance,

Guillaume.

[1] https://devcenter.heroku.com/articles/buildpack-api#stacks
[2] http://docs.cloudfoundry.org/devguide/deploy-apps/environment-variable.html
[3] https://www.pivotaltracker.com/story/show/76910170
[4] https://devcenter.heroku.com/articles/cedar-ubuntu-packages

[jche...@pivotal.io]

Hi Guillame;

I'm Jacques from the CF Buildpacks team.

Currently we wrap Heroku's buildpack code for Ruby, Python, PHP and Node. Of these, the Ruby buildpack is furthest down the path of supporting multiple stack settings according to the STACK environment variable.

Heroku's runtime environment is sufficiently different from ours that we can't run their code as-is without introducing regressions. Consequently there has been ongoing work to manipulate the STACK variable and related variables in order to ensure that Heroku's code operates without change in our environment. We introduced a collection of related changes in 1.1.2[1]. The most important of these is that we forcefully set the value of STACK to '', the empty string, before entering the Heroku code. It's set to the empty string because Heroku's code can handle that case, but causes faults if we set a value such as "lucid64". Different faults are introduced if we set it to "cedar".

We are currently working a regression that 1.1.2 introduced[2], due to the fact that Heroku are now building all their binaries in both cedar or cedar-14 variants, starting with ruby 2.1.3.

The other buildpacks have not yet, to our knowledge, introduced changes that break as badly in our environment as the Ruby buildpack has.

Diego's multi-stack support refers to the Cloud Foundry concept of a stack. The CF and Heroku concepts of a "stack" are similar, but sufficiently different that the Diego stories can give a misleading impression of what's happening. For CF-supported buildpacks apart from Java, you can follow activity on the CF Buildpacks tracker[3].

I hope this helps outline the current situation.

Cheers,

JC.

[1] https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.1.2

[2] https://www.pivotaltracker.com/story/show/80934254

[3] https://www.pivotaltracker.com/n/projects/1042066

[Guillaume Berche]

Thanks Jacques for the detailed description of how the buildpacks team is currently handling the STACK variable expected in heroku buildpacks, this is quite helpful.

I guess that in the future, as multi stacks gets introduced in CF, a CF runtime mechanism will provide this information to buildpacks, as to avoid having each of them configure [1] or autodetect [2] the current stack as Daniel's buildpack or java-buildpacks are currently doing.

Guillaume.

https://github.com/dmikusa-pivotal/cf-php-build-pack/blob/aa3d47d73d59768b6fcfc53a5ad28713febed28a/defaults/options.json#L6
https://github.com/cloudfoundry/java-buildpack/blob/6d686064b966231e2ecaa4e3a5f1796ae118b0f7/lib/java_buildpack/repository/repository_index.rb#L84

[Jacques Chester]

I believe that as we introduce our own stack distinction, it will be published as an environment variable that buildpacks and apps can check.

What this means for our work in buildpacks is left as an exercise for the buildpacks team :)

Cheers,

JC.