Labels

Milestone

Assignee

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.

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.

@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 think the boolean of release/no_release is a bit more vague now… I think
right now :no_release is basically DB servers… but it could also be asset
servers…
Maybe I'll add another :role for assets (and document it appropriately)
- Lee

I can think of at lest two companies I've worked with on deployments before,
where to them an "asset" server is a CDN proxy, which builds the assets, and
syncs them with cloudfront, or some other service, but doesn't have any
responsibility for serving them itself (except until the synchronisation is
complete)

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?

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.

On 8 July 2011 00:22, cgriego < reply@reply.github.com>wrote:
@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.
```ruby
load 'deploy'
load 'bundler/capistrano'
load 'deploy/assets'
```
--
Reply to this email directly or view it on GitHub:
https://github.com/capistrano/capistrano/pull/35#issuecomment-1526831

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.

@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.

@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.

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
Hambley)
* Removed the `VERSION` file (Lee Hambley)