heroku-geo-buildpack icon indicating copy to clipboard operation
heroku-geo-buildpack copied to clipboard

Build sometimes working, sometimes not

Open guybowden opened this issue 8 years ago • 14 comments

I have a cedar-14 app using this buildpack - it apparently builds fine every time, but sometimes the libraries are not present in /app/.heroku/vendors/lib

This seems to happen if I see these lines in the build log.

remote: -----> Fetching and vendoring geos
remote: -----> Fetching and vendoring gdal
remote: -----> Fetching and vendoring proj

A re-deploy fixes the issue.. I don't see those lines above, but the libraries are placed in the lib directory..

guybowden avatar Oct 21 '15 23:10 guybowden

I'm also seeing this.

kennethreitz avatar Feb 08 '16 22:02 kennethreitz

Just reviewed all the code, and everything looks relatively sane. Going to dig deeper.

kennethreitz avatar Feb 08 '16 22:02 kennethreitz

I have tried explicitly making an /app/.heroku/vendors dir instead of using the shell script variables but no joy. My workaround after a cache purge is now to push an empty Python + Geo app up THEN re push my actual app. (My actual app has a bin/post_compile script that dies if the libs aren't where they should be so the build fails and no cache is created)

Somehow the official Python build pack manages to create the vendors dir every time. Here's hoping! On Mon, 8 Feb 2016 at 23:47, Kenneth Reitz [email protected] wrote:

Just reviewed all the code, and everything looks relatively sane. Going to dig deeper.

— Reply to this email directly or view it on GitHub https://github.com/cyberdelia/heroku-geo-buildpack/issues/33#issuecomment-181606293 .

guybowden avatar Feb 09 '16 05:02 guybowden

I find the exact same thing as @guybowden - pushing an empty Python Django app that doesn't require the geo libraries to get new clean image set up, then pushing the actual app after that and everything works. Subsequent pushes work without a problem, using the cache.

longhotsummer avatar Feb 15 '16 10:02 longhotsummer

This line may be to blame

https://github.com/heroku/heroku-buildpack-python/blob/master/bin/steps/python#L18

kennethreitz avatar Feb 16 '16 21:02 kennethreitz

Interesting. If that's true, then is the python buildpack not playing nicely with other buildpacks that put libraries into .heroku/vendor, or is the python buildpack allowed to do that? If so, should this buildpack put its libraries somewhere other than .heroku/vendor?

longhotsummer avatar Feb 17 '16 06:02 longhotsummer

The real problem here is the first push triggers this behavior, a "stack change". That is likely a bug.

kennethreitz avatar Feb 17 '16 06:02 kennethreitz

What sets the default STACK variable in Dokku? According to this https://github.com/heroku/heroku-buildpack-python/blob/master/bin/compile#L148 the $CACHED_PYTHON_STACK gets set to $DEFAULT_PYTHON_STACK which is cedar. Perhaps that should be $CACHED_PYTHON_STACK=$STACK

longhotsummer avatar Feb 17 '16 06:02 longhotsummer

oh, cedar-11 builds are permanently disabled now, so this appears to easily fixable. But there will be another stack in the future, so this will just come into play once more. Will need to evaluate carefully.

kennethreitz avatar Feb 17 '16 07:02 kennethreitz

Okay, I believe I have now fixed this.

kennethreitz avatar Feb 25 '16 19:02 kennethreitz

@longhotsummer your suggestion was correct :)

kennethreitz avatar Feb 25 '16 19:02 kennethreitz

So, the Python buildpack will no longer wipe the contents of .heroku/vendor on the first push of an application. I believe that was the cause of this bug.

It will still do so whenever the stack changes. This almost never happens (once every 2-3 years?).

kennethreitz avatar Feb 25 '16 19:02 kennethreitz

Great stuff - thanks for sorting

guybowden avatar Feb 25 '16 21:02 guybowden

Brilliant, thanks @kennethreitz

longhotsummer avatar Feb 26 '16 07:02 longhotsummer