Difference between current_path vs release_path in Capistrano?

Question

What is the difference between the current_path and release_path path variables in Capistrano, as in

task :path do
    on roles :app do
        puts "Release path: #{release_path}"
        puts "Current path: #{current_path}"
    end
end

Does the current_path always contain the most up to date code?

Answer 1

Since this hasn't got a satisfactory answer I'll add what I've found out.

Looking at this blog post we can see where path variables point:

current_path – path of deploy_to + current_dir (e.g. /u/apps/example/current ) release_path – path of releases_path + release_name (e.g. /u/apps/example/releases/20100624000000 )

So to answer your question: yes, current_path does point to the most up to date code (the most recent deployment). It points here through a symlink to the latest release directory. Take a look at the capistrano structure if you're interested in what all the folders mean.

The difference with release_path is that it points to the path of the release you are currently deploying. This is useful if you want to reference a file in your repo during the deployment, such as run a script.

However, release_path is only updated during the deploy:starting namespace, at any other time, it's exactly the same as current_path. See this github isssue for more information.

My particular use case was I wanted to run a composer install using the composer.phar that's located in the root of my repo. So, following the documentation I did this:

SSHKit.config.command_map[:composer] = "#{release_path}/composer.phar"

But that didn't work, because at the time this is defined, release_path still points to the current_path.

The workaround I found for this comes from this answer and it's to evaluate the release_path lazily:

SSHKit.config.command_map[:composer] = lambda { "#{release_path}/" + fetch(:src_path) + "/composer.phar" }

So as long as the variable is accessed after the deploy:starting namespace, release_path will be set as we expect it.

Answer 2

I feel compelled to answer here to clarify some things about current_path and release_path

Capistrano works in stages, so for the sake of this answer I will describe the important stages as follows.

Stage 1: before current_dir is relinked

In my version of Capistrano that I'm looking at, the "linking" of the 'current' directory occurs in task

deploy:create_symlink

But you should check your capistrano setup for the exact taskname. It is easy to see in the capistrano terminal output, just look for the sshkit call to "ln -s".

PRIOR to this step running:

• current_dir is the path to the symlink, pointing to the last directory creating by the last [not current] run of capistrano. NOT REALLY CURRENT IS IT? Or not for long anyway.....
• release_dir is the most recently checked out version created in this run of capistrano.

So take special note, anything working in current_dir at this stage is working in the wrong place.

Stage 2: after current_dir is relinked

AFTER the symlinking step runs [it will run "ln -s" on the release_dir, linking to current_dir (its not really a directory, its a link. Anyway.....)]

• current_dir is the path to the symlink, pointing to the release_dir. Now it really is current.
• release_dir is the most recently checked out version created in this run of capistrano.

At this stage, it no longer matters whether your tasks are working in release_dir or current_dir, they are pointing at the "same" files on the disk.

Why is this important?

Working before the symlink is changed is typically preferable because, if there's a failure, nothing is disrupted. At this stage, you must use release_dir.

If you are working after the symlink has changed, you could still use release_dir. If you are using current_dir, ask yourself why not use release_dir, and ask yourself why you have these build steps running after the symbolic link changes. If you can move them before the symlink changes, you should. In the setup I am looking at, I do this with

before "deploy:create_symlink",  "a_task_that_must_use_release_dir"

If you are working in current_dir after the symlink changes, and before your webserver restarts, and you encounter a problem, you may have trashed your environment.

Does this make current_dir evil? I don't think so, with great power comes great responsibility.

Answer 3

Each time you are deploying Rails application with Capistrano a new directory will created with newer version as filename in Releases Directory. This directory contains most updated code. and the current symlink directory will point to the latest created directory to run the application.

The tasks rake,bundle etc will run on shared path directory which creates separate directories

we can revert back a release usning rollback command like

 cap deploy:rollback # capistrano 2
 cap stage_name rollback  #capistrano 3

Hope it helps you.