Add support to recompile slug without a push or config change #514

NeoPhi opened this Issue Aug 15, 2012 · 14 comments


None yet

NeoPhi commented Aug 15, 2012

Using cedar with a node.js package if you don't specify explicit versions in a package.json and a referenced project is updated in order to get the slug to recompile you have to push a change. In most cases I don't want to have to make a code change but instead just want to recompile the slug so it pulls down the latest version of packages referenced via package.json. Adding support for this would be handy.


geemus commented Aug 16, 2012

@NeoPhi - I can certainly see how this would be useful, but it's a bit beyond my area of expertise at the moment.

@ddollar - thoughts and/or advice on who I should talk to about this?


ddollar commented Aug 16, 2012

@NeoPhi If you're up for trying something experimental, check out as an alternate way to build that is not reliant on git push

This feature is vital for debugging any problem with slug compilation.

Meanwhile, workaround:

git commit --allow-empty -m "empty commit"
git push heroku master

jkarmel commented Oct 4, 2012

Just wanted to add my support for a heroku recompile, really annoying adding pretend commits when I update a referenced project.


wuputah commented Dec 12, 2012

Are there any use cases here outside of triggering npm rebuild and recompiling assets when using user_env_compile?

We generally don't think you should ever have to recompile your code. Builds should be as deterministic as possible - you should be able to rebuilt and get the same result. They shouldn't depend on your configuration (though user_env_compile allows this, there's a reason it's in labs). There are, of course, exceptions, such as outside resources becoming unavailable or something changing on the platform (such as the default version of ruby or node, provided you don't set one).

In my opinion, the problem lies with npm: it doesn't provide a lockfile similar to Bundler's Gemfile.lock, so there's no deterministic way to define what dependencies you will get.

Hi JD. When I wrote my comment, slug compilation was crashing due to a bug in Heroku. This is thankfully rare, but being able to rebuild the slug at will would have made the issue much easier to distil and report.

I agree slug compilation should not be encouraged to update packages, because it risks software rot. To make slug compilation deterministic, Gemfile.lock is perfect solution.

There's actually a new feature in Npm npm shrinkwrap analogous to Gemfile.lock. Heroku doesn't use this, but totally use this. This would solve OP's problem and be penicillin against software rot. I've opened a new issue suggesting that heroku#650

+1. This would be useful for both our Node and our Java based projects


wuputah commented Jan 20, 2013

We're working towards opening up build as a separate service, separate from git. See:

wuputah closed this Jan 20, 2013

slothbear referenced this issue in railsbridge-boston/railsbridge-boston Jun 27, 2013


Heroku/Git #11

agconti commented Mar 10, 2015

+1 for heroku recompile. Using and empty commit works:

git commit --allow-empty -m "empty commit"
git push heroku master

But it creates an unnecessarily dirty commit history.

csuhta commented Mar 10, 2015

@agconti You can now use this to rebuild without creating commits:

damienfa commented Aug 4, 2016

@csuhta ... heroku/heroku-repo do not have a "rebuild" command ? What is your point ?

csuhta commented Aug 4, 2016 edited

@damienfa heroku-repo lets you blow out your Heroku build caches and Git remote. So one of the ways you can completely rebuild/recompile your application without making any new Git commits is:

heroku plugins:install
cd your-app
heroku repo:purge_cache
heroku repo:reset
# This will rebuild your app because the Heroku Git remote is 
# now a freshly empty/initialized repo again
git push heroku master 

+1 for implementing it. @csuhta your approach worked perfectly for me. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment