Closed sykesm closed 10 years ago
We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: http://www.pivotaltracker.com/story/show/70019590. This repo is managed by the 'Runtime Diego' team.
That's surprising to me, are you using the latest code? We just made thus work a few days ago.
This is the other buildpack cache, which we do not plan to support. The 700mb tarball. On Apr 23, 2014 9:22 AM, "Matthew Kocher" notifications@github.com wrote:
That's surprising to me, are you using the latest code? We just made thus work a few days ago.
— Reply to this email directly or view it on GitHubhttps://github.com/cloudfoundry-incubator/stager/issues/4#issuecomment-41182267 .
@mkocher i'm using diego code from master and the latest cf-release - including the current ruby buildpack (not the new buildpack in master).
@vito I'm happy the cache is dead - it's just an incompatible change. I assume the STAGING_TIMEOUT
variable was also explicitly omitted because of its spurious usefulness?
@sykesm right, it's an incompatible change but to a nonstandard buildpack interface. these are both variables only assumed by our forks of buildpacks, and the newer ruby buildpack has removed this behavior: http://github.com/cloudfoundry/cf-buildpack-ruby
I just tried pushing a ruby application and it failed during
detect
becauseBUILDPACK_CACHE
was not set in the environment. While this isn't something that should be needed bydetect
(seems like a bug in the buildpack), it is an incompatibility with the legacy staging process.I assume the goal was to keep the staging process compatible with the legacy dea? If so, should the
BUILDPACK_CACHE
be exported to the staging process?