Rails 3.1 Asset Pipeline support #35

merged 1 commit into from Aug 3, 2011


None yet

8 participants


I haven't dug into the details yet, but deploying Rails 3.1 will need some special consideration for the new asset pipeline support. I think it will mainly be symlinking a public/assets folder to the shared folder and running a precompile rake task. The tricky thing will be not breaking Rails < 3.1 apps.


I'm really struggling with figuring out how to handle the rake assets:precompile task. I'm considering requiring the application load a "deploy/assets" recipe to get this functionality.


There are other tools already in use that have asset compilation steps. Maybe it's as simple as having a variable that defines what the asset pre-compilation rake task is and run it only if it is defined and then update the generated deploy.rb to document it.


Pull request added. Not the cleanest thing in the world but it's in line with people's expectations of Capistrano 2.x.


Wait, I forgot about symlinking the assets folder to share unchanged assets across deploys. I think given that part of it, I'll go back to the idea of making it an additional recipe load.

Capistrano member

Thanks @cgreigo - I'll get to reviewing and merging all these pull requests towards the end of the week, so we'll get something out of the door this month.

Capistrano member

@sheldonh - thanks I believe I have enough information between you and @cgriego to do a decent job of getting this out of the door this weekend, watch this space for a pre-release :)


@leehambley I've updated the pull request with a separate recipe that better supports the Rails 3.1 asset pipeline but it doesn't make any attempt to support any other asset compilers. This uses the best practices DHH outlined in his RailsConf keynote (namely the symlinking assets across deploys).


I'm wondering if deploy:assets:symlink should run on any server with a release and not filter to just web servers. I could go either way.

Capistrano member

@leehambley I don't buy it. What makes an asset role distinct? What is a web server if not a server for assets?

Capistrano member

Help me understand. I don't see the functional difference between a server with the :web role as capistrano treats it now and an origin server for a CDN.


Is this going to be merged anytime soon?

Capistrano member

When using this patch with bundler/capistrano recipes deploy:assets:symlink failing because the recipes are executed before bundle install. Any way to get bundler's recipe executed before deploy:assets?


@aganov I'll have to change how the recipe hooks in.

Bundler runs the bundle:install task after deploy:update_code. Right now the assets recipe is running the asset precompile task after deploy:finalize_update which happens in the context of deploy:update_code.

There's no good common hook outside of deploy:update_code though, so the asset task could be changed to also hook in and run after deploy:update_code, but then in order to get the Bundler task to run before the asset recipe, you'll be dependent on the load order of the recipes, which would be pretty problematic in real world use.

load 'deploy'
load 'bundler/capistrano'
load 'deploy/assets'
Capistrano member

Unfortunately I don't think there is a sane additional hook to pick here. finalize_update is the sane hook and it already exists. I'm going to make the changes to this patch that allow it to work with Bundler in an load-order-dependent mode and then submit a patch to Bundler to change it to use the proper hook. I trust @indirect will merge it pretty quickly.


Updated this pull request and sent the pull request to Bundler.



You will also need to create a shared cache directory for the cache:

/tmp/cache/assets/ is used as the default cache directory


Otherwise the cache will be lost with each deployment.


@rhulse Great catch, I'll get that worked in this weekend.


Cool. I'll update the asset pipeline docs when it is merged into master.


I also need to add a variable for the assets path since it can be configured in Rails by setting assets.prefix.


Removed the cache symlinking because it turns out it is not supposed to be shared.

Capistrano member

@cgriego - great work on this, please give me a nod when you feel it's ready to be merged (or better yet, collapse the history into one clean commit I can pull) - I'll keep my eyes on this pull req. until such time as it feels like it's calmed down, or you tell me you're happy with it.


@leehambley Added one small last fix from my testing and I've squashed. It's ready to go.


Do you have to set :assets_prefix in the project's deploy recipe, if you are not using the default of 'assets'?


Scratch that last comment, there is a bug. You have not use the param #{assets_prefix} every time in lines 23 and 24 of the patch.

This will cause issues for people who are using /assets as shared already. (Cannot offer a patch sorry, not git access from the office).


@rhulse The assets_prefix variable is used to control the public path only and mirrors the Rails config option. The shared directory is a Capistrano concept and doesn't use the variable by design. The shared directory, being shared across deploys, needs to use stable, reserved names despite changes between users' individual deploys, like changing the prefix from one deploy to the next. No other shared directory name is configurable in the deploy recipe. This won't cause anyone who already has a public/assets directory any problems but it will if they have written custom recipes that setup a shared/assets folder and try to load the assets recipe but if they already have a custom assets system setup then they won't need to load this recipe.

@leehambley leehambley merged commit 228d686 into capistrano:master Aug 3, 2011

This is good, but what about not running precompile task, if it is not needed? Example in this blogpost - http://www.bencurtis.com/2011/12/skipping-asset-compilation-with-capistrano/

Capistrano member

@daeltar please feel free to open an issue and/or send a patch (ideally making this configurable) - nothing will change from a commit comment!


@pacoguzman Thank you for your constructive feedback.

Excuse me, that was the first thought after found what broke our deploy. We'll try to figure out a constructive way to solve our problems

@jdilag jdilag added a commit that referenced this pull request Sep 17, 2014
@jdilag jdilag Fixed svn.rb fetch_revision
fixed error thrown by line #35 on deployment process
@jsonn jsonn pushed a commit to jsonn/pkgsrc that referenced this pull request Oct 11, 2014
gls Update sysutils/capistrano to 2.8.0
Upstream changelog:

  ## 2.8.0 / August 3 2011

  A short release, after the last. Announcing Rails 3.1 asset pipeline support.

  The asset pipeline support requires an additiona `load` in your `Capfile`.

  You can see information pertaining to the pull request, including the inline
  comments here: capistrano/capistrano#35

  Documentation will be available soon in the wiki.

  * Drop-In Rails 3.1 asset pipeline support. (Chris Griego)

  ## 2.7.0 / August 3 2011

  A fairly substantial release. There are fixes so that current_release works
  during dry-runs, (although, apparently still not with bundler.)

  The test-suite was also modified to work with Ruby 1.9.2, except in one case
  where Ruby 1.9.x calls `to_ary` and `to_a` on mocks, which still makes an
  error. 1.9.x has always been supported, but due to lack of maintenance on my
  part the tests didn't ever pass.

  The `start`, `stop` and `restart` tasks have been reduced to mere hooks into
  which extensions can define their own functionality.

  The `readme` was also slightly improved, simply tweaks to express how best to
  run the test suite.

  * Ensure dry-run works with `:current_release` variable (Carol Nichols)
  * Added a new variable `:git_submodules_recursive`, setting the value to false
  will ensure Git doesn't recursively initialize and checkout submodules. (Konstantin Kudryashov)
  * Added an additional task option, `:on_no_matching_servers`, setting the
  value to `:continue` will ensure tasks with no matched servers continue
  without error, instead of raising `Capistrano::NoMatchingServersError` as was
  the previous behaviour. (Chris Griego)

  A huge thanks to all contributors, as always!

  Remember: @capistranorb on twitter for news.

  ## 2.6.1 / June 25 2011

  A short maintenance release, Some fixes to the verbose flag inside the Git SCM
  as well as another argument for the (internal) `variable()` command, offering
  a default. The Git SCM is now verbose by default, but can be disabled by
  setting `:scm_verbose` to false.

  There has been an additional method added to string, within the context of the
  test suite, I'm always sketchy about adding additional methods to core
  classes, but it's a short term fix until I make the time to patch the test
  suite not to compare strings literally. The method is `String#compact`, and is
  implemented simply as `self.gsub(/\s+/, ' ')`.

  Here's the run-down of changes, and their committers, as always - a huge thank
  you to the community that continues to drive Capistrano's development.

  * `deploy:setup` now respects `:group_writable` (Daniel Duvall)
  * Fixes to `:scm_verbose` for the Git module (defaults to On.) (Matthew Davies)
  * Will now copy hidden files in the project's root into the release
  directory (Mark Jaquith)
  * Now handles closing already-dead connections in a sane way (does not raise
  an exception) (Will Bryant)
  * Renamed `Capistrano::VERSION::TINY` to `Capistrano::VERSION::PATCH` (Lee
  * Removed the `VERSION` file (Lee Hambley)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment