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.
Noticed that a similar request appeared on stackoverflow http://stackoverflow.com/questions/9713183/recompile-heroku-slug-without-push-or-config-change
@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?
@NeoPhi If you're up for trying something experimental, check out https://github.com/ddollar/heroku-anvil as an alternate way to build that is not reliant on git push
This feature is vital for debugging any problem with slug compilation.
git commit --allow-empty -m "empty commit"
git push heroku master
Just wanted to add my support for a heroku recompile, really annoying adding pretend commits when I update a referenced project.
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
We're working towards opening up build as a separate service, separate from git. See: https://github.com/ddollar/anvil
+1 for heroku recompile. Using and empty commit works:
But it creates an unnecessarily dirty commit history.
@agconti You can now use this to rebuild without creating commits: https://github.com/heroku/heroku-repo
@csuhta ... heroku/heroku-repo do not have a "rebuild" command ? What is your point ?
@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 https://github.com/heroku/heroku-repo.git
# 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!