Rails asset caching

[lneffa]

Hi, first thank you for the sample setup. I've followed the steps described to run the sample setup locally as well as for deployment. Building the assets into /public/assets on heroku deploy works up until noticing that the gulp rev is having no effect on what Rails serves as assets. When inspecting the response of the digested application-xxx.css file, the asset paths have not been updated to match rev-manifest.json.

config.serve_static_files is true for production, as well as the other setup instructions have been followed for deployment.

I'm suspecting Rails asset caching is interfering during production. This is also my guess since looking into the dyno tree shows old assets: $ heroku run bash ... ~/public/assets/fonts $ ls -l total 44 -rw------- 1 u58246 58246 1140 Mar 2 19:57 gulp-rails-icons-02b88d2d.woff -rw------- 1 u58246 58246 1856 Mar 2 19:57 gulp-rails-icons-0e6afbba.ttf -rw------- 1 u58246 58246 1140 Mar 2 19:49 gulp-rails-icons-463bf8ff.woff -rw------- 1 u58246 58246 1856 Mar 2 19:49 gulp-rails-icons-74cc4a04.ttf -rw------- 1 u58246 58246 3180 Mar 2 19:49 gulp-rails-icons-9249053b.svg -rw------- 1 u58246 58246 2056 Mar 2 19:49 gulp-rails-icons-d62f0c22.eot -rw------- 1 u58246 58246 2056 Mar 2 19:57 gulp-rails-icons-ef16004a.eot -rw------- 1 u58246 58246 2056 Mar 2 19:37 gulp-rails-icons.eot -rw------- 1 u58246 58246 3180 Mar 2 19:37 gulp-rails-icons.svg -rw------- 1 u58246 58246 1856 Mar 2 19:37 gulp-rails-icons.ttf -rw------- 1 u58246 58246 1140 Mar 2 19:37 gulp-rails-icons.woff

Can I get some help in configuring the deploy process so during remote production build I can match exactly what gets spit out as assets by Rails in this repo? :
https://gulp-rails-pipeline.herokuapp.com/

[lneffa]

So I figured out what was going on, took me some time as I had been developing in Node before becoming a newcomer to Ruby and then the asset pipeline.

Sprockets keeps a cache of builds targeting ./public/assets. The amount of caching has been open to changing, but instead of changing this amount, I realized that caching was not the problem as part of a build process, but a problem when modifying ./public/assets with gulp in the incorrect order.

I used this command https://github.com/heroku/heroku-repo#purge_cache to 'help' empty cached Sprockets files.

I would also recommend using the rails_12factor gem as it helps setting up Heroku envs and Rails configs.

[mhodgson]

@audeamus22 Can you clarify a little more? I'm running into the same issue and also finding that the only solution seems to be manually purging the cache between each deploy. Have you found an automated way to make sure the fresh gulp assets are served?

@greypants interested to hear if you've had similar problems and how you've fixed it.

Thanks

[lneffa]

@mhodgson, I changed my username.. and unfortunately I have not! I have looked here and went through shared links: https://github.com/heroku/heroku-buildpack-ruby/issues/123

Nothing had pointed to an automated way. I'm assuming that since $ heroku repo:purge removes files cached during build, some asset pipeline configuration or middleware gem keeps storing and referencing build files. This ends up happening on running $ rake assets:precompile during the ruby chunk of the multipack build.

[greypants]

Interesting... I'm gonna re-open this for visibility if other people are running into the same issue. We just started using it on our first client project this week, which didn't end up being hosted on Heroku—so we hadn't hit issue yet. Thanks for posting your solutions, and let us know if you think of an elegant way to fix it. I'll take a look when I get some time.

[greypants]

Finally hit this today :(

[lneffa]

@greypants have you been able to fix your problem?

[greypants]

I've been kicking it down the road, but will likely have to deal with it this week. I'll let you know.

[greypants]

@lneffa what were the exact steps you took to fix the issue? At what point in the process did you run heroku repo:purge? Right before deploy?

[lneffa]

@greypants Yepp, ran it before each deploy

[greypants]

ooook. So in my current setup (not merged here yet), this shouldn't be an issue. I'm hashing every asset filename, including the css and js files that get pulled into the sprockets manifests. That should bust heroku's caching as well. Super busy right now, but as soon as I get a chance, I'll update this repo with the new file reving stuff.

[joaovpmamede]

@greypants so is it just a matter of changing this line?

https://github.com/vigetlabs/gulp-rails-pipeline/blob/master/gulp/tasks/rev/rev-assets.js#L7

[greypants]

@joaovpmamede no, it's more complicated than that.

[joaovpmamede]

Oh ... any chance of updating the repo?

[rowanoulton]

@greypants any chance you could share your solution for this? Cheers!

[orlando]

Well I just came across this issue, the problem is that heroku-buildpack-ruby is caching and overwriting assets on every deploy. Since rev-manifest.json has the same filename on every deploy, it gets overwritten by the cache with an older version.

I forked the buildpack (https://github.com/orlando/heroku-buildpack-ruby) and changed how cache is loaded, instead of replacing all files, only copy the files that are missing (given that we have a step that prepopulates public/assets directory).

So, probably if you use the fork, your cache issue will be solved.

I'll submit a PR but I don't know if this will get merged or if it's useful for other developers

[rowanoulton]

@orlando excellent solution, definitely useful in my case. Thank you!

[greypants]

nice!

[orlando]

https://github.com/heroku/heroku-buildpack-ruby/issues/402 was merged, but is not released yet.

In the mean time you can use in your .buildpacks file

https://github.com/heroku/heroku-buildpack-nodejs
https://github.com/orlando/heroku-buildpack-ruby

@greypants I think we now can close this issue

[greypants]

Nice work! :+1:

[chadwhitacre]

heroku/heroku-buildpack-ruby#402 was merged, but is not released yet.

What's the difference between merge and release in this context? Since buildpacks are specified using a Git URL, aren't changes "released" immediately upon merge?

When I git clone https://github.com/heroku/heroku-buildpack-ruby.git, it includes https://github.com/heroku/heroku-buildpack-ruby/commit/613defce8ec18b6416d527d2183db93cf8702b28.

[chadwhitacre]

Buildback link changed in https://github.com/whit537/gulp-rails-pipeline/commit/630c01d8e073091f693bcde34579e68dde6391b9 under #40.

[orlando]

@whit537 this is due https://github.com/heroku/heroku-buildpack-ruby/pull/402#issuecomment-128072117, I think that unless you specify the buildpack, heroku will choose the last release (not 100% sure tho)

If you can try it I'm cool removing the README entry

[orlando]

@whit537 Actually you are right, we can remove that, they already released an stable version including these changes.

I'll submit a PR just removing the README comment

[chadwhitacre]

We also like to keep changes there for at least a few days to see if anyone has a problem with a change before doing a proper deploy.

@orlando Yeah, that does make it sound like there's an additional deploy/release step for these buildpacks, presumably before they're used in Heroku's default buildpack-sniffing case. For our purposes here, since we're using multi-buildpack and explicitly specifying the Git URL in .buildpacks, it seems to be enough that https://github.com/heroku/heroku-buildpack-ruby/pull/402 is merged to master over there.

[chadwhitacre]

they already released an stable version including these changes.

Where are you seeing that?

[orlando]

@whit537 check their changelog

[chadwhitacre]

@orlando Yeah, but that would've been updated instantly as soon as they merged 402. Right?

[orlando]

@whit537 Oh sure you are right, brainfart after that PR got merged. Also your PR is just README fixes, I thought you had other changes in there.

I'll close #41 in favor of yours, but it will be cool if you can squash those commits.

[chadwhitacre]

https://devcenter.heroku.com/articles/buildpacks could be read as indicating that the sniffed buildpacks (and the shorthands) don't necessarily use master. Hmm ... https://github.com/heroku/heroku-buildpack-ruby/pull/402#issuecomment-160678601. :-)

[chadwhitacre]

I'll close #41 in favor of yours, but it will be cool if you can squash those commits.

Okay, cool. Will do ...

[chadwhitacre]

the sniffed buildpacks (and the shorthands) don't necessarily use master. Hmm ...

Turns out that the vNNNs in the CHANGELOG are the result of an "internal procedure and service for 'deploying' a buildpack," which also results in a new release on GitHub. Mystery solved! :-)

https://github.com/heroku/heroku-buildpack-ruby/pull/402#issuecomment-160681255

[orlando]

@whit537 :smiley:

[greypants]

:+1: