meteor-buildpack-horse: Push rejected, failed to compile Node.js app. Meteor 1.2

This is very strange:

-----> Meteor version: Meteor 1.4.0.1 and the .1.4.0-1 in the cp path imply that your .meteor/release is 1.4.0.1. However, the directory /app/tmp/cache/1.2.1/ implies that your meteor release is 1.2.1.

It looks as though somehow Meteor v1.4.0.1 got installed even though you requested v1.2.1. Could you check the value of .meteor/release?

If it is METEOR@1.2.1, can you please set an environment variable to clear the cache so that meteor gets reinstalled?

heroku config:set BUILDPACK_CLEAR_CACHE=1

I wonder if install.meteor.com/?release=<VERSION> is unreliable, and occasionally delivering a different version than requested. Trying to think if there’s any other way this could have happened.

heroku config:set BUILDPACK_CLEAR_CACHE=1 did the trick for me too.

@jsantana90 heroku config:set BUILDPACK_CLEAR_CACHE=1 should fix it

Adding BUILDPACK_CLEAR_CACHE worked and now I can deploy successfully. Should I leave this environment variable set? or am I safe to take it out?

Please try the beta release of meteor-buildpack-horse, which should fix problems with locating node/npm within the build, and no longer relies on install.meteor.com/?release=<version> (which is unreliable). It also fixes the cache usage so that we don’t rely on the version of meteor in the cache being identical to the target release in .meteor/release.

heroku config:unset BUILDPACK_CLEAR_CACHE
heroku buildpacks:set https://github.com/AdmitHub/meteor-buildpack-horse.git#beta

@RobertLowe, we are not using meteor node or meteor npm. Instead, we’re searching within the meteor bundle for node and npm. This is necessary not only to support older meteor’s, but also so that we can copy the node binary into the built slug for space-efficient execution of node.

This buildpack does have full support for meteor from 1.0 to 1.4. This issue concerns a problem with meteor deciding to upgrade itself without us intentionally asking it to; and I still don’t know why. Currently, the reliable workaround is to heroku config:set BUILDPACK_CLEAR_CACHE=1, which clears existing meteor installations at the start of every build. This increases build time a bit, but works around any unwanted upgrades meteor throws at us.

@Philip-Nunoo I know, but as @yourcelf stated, this is just a workaround, it should by default work without it.

Can’t seem to deploy without the BUILDPACK_CLEAR_CACHE trick

remote: Building source:
remote: 
remote: -----> Node.js app detected
remote: -----> Meteor version: Meteor 1.4.0.1
remote: -----> Checking if this meteor version supports --server-only
remote: cp: cannot stat ‘/app/tmp/cache/1.3.3.1/.meteor/packages/meteor-tool/.1.4.0-1.1y1hz1n++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/bin/node\n/app/tmp/cache/1.3.3.1/.meteor/packages/meteor-tool/.1.3.3_1.9tltar++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/bin/node’: No such file or directory
remote:  !     Push rejected, failed to compile Node.js app.
remote: 
remote:  !     Push failed
remote: Verifying deploy....
remote: 
remote: !   Push rejected to myapp.

METEOR@1.3.3.1 with master branch buildpack