Rename symlink task to create_symlink #12

Merged
merged 2 commits into from Apr 2, 2013

Projects

None yet
@snmaynard

Raisless deploy is still using deploy:symlink. Capistrano is moving over to create_symlink.

@leehambley

Feel like sending a pull request?

@dominics

Worked well for me with Capistrano 2.13.4. Thanks!

@loopj

@leehambley this is a pull request! :)

@leehambley

The weekend rolled around, and I should have some time to take care of this, my worry is taking a breaking change back upstream, so I'll need to introduce a proxy method to catch people's existing before/after callbacks before I can release this.

@loopj

Hey Lee, did you get time to make this change yet? I'm finding myself pointing to @snmaynard's fork.

@victorcoder

Same here, would be great to have this merged. Thx

@wkoffel

Also wondering if there's a new official gem release of railsless-deploy in the works that's compatible with the new capistrano. Been holding back on the upgrade hoping for something here, rather than forking a gem for it.

@leehambley

Also wondering if there's a new official gem release of railsless-deploy in the works that's compatible with the new capistrano.

What do you mean compatible with the new Capistrano? The recipes are completely independent, as long as you use this, the symlink task is deploy:symlink, in up stream capistrano it's called deploy:create_symlink, but that's not a question of compatibility, railsless-deploy simply uses the framework from Capistrano, but all deployment related naming and behaviour is isolated to this gem.

I'm concerned about renaming the symlink task here, and being stuck with breaking changes for people, and not having sufficient time to support that.

@dominics

Is the rationale for the rename upstream (leaky global Rake methods) relevant for capistrano-railsless too?

As you know, when this change originally hit crapistrano proper there was a lot of heat and ranting (I think until both names were hooked, with a deprecation warning for the old one). So, I think you're right to be concerned.

@leehambley

Is the rationale for the rename upstream (leaky global Rake methods) relevant for capistrano-railsless too?

Yes, but that issue was promptly fixed in the Rake v0.9.x series, and following the release of Rake v10.0.0 in the last day or two, those things are completely removed from Rake. (it looks like the rake changes are still in a branch, and haven't made it to master, yet)

I believe in Capistrano the final change (I wrote the code, actually but it was almost a year ago!!) rewrote deploy:symlink to Kernel.warn about the rename, and then simply call deploy:create_symlink.

There are a number of other upstream changes to Capistrano that didn't make it in here, yet namely:

  • A fix to the rollback handling
  • deploy:web:{enable,disable} were removed
  • capistrano-colours was removed
  • shared_children was used natively by symlink tasks
@leehambley

if @snmaynard changes his pull request to reflect the fact that deploy:symlink throws a warning, and then call the original task, I'll merge it in a heartbeat!

@medlefsen

@leehambley https://github.com/capistrano/capistrano/blob/master/lib/capistrano/configuration/callbacks.rb#L118

With the newer capistrano we can't hook deploy:symlink any more. Also, unlike with vanilla capistrano, we can't just switch the hook to deploy:create_symlink.

Ideally I'd prefer to see capistrano use a better way to handle deprecation but perhaps renaming to match vanilla is a good short term option.

@renan
If you want to get the most out of Capistrano and you do not want to have to deal with the railsisms that ship by default, this is the gem for you.

The newer version of Capistrano doesn't seems to have this railsisms anymore. Is this gem still needed?

@leehambley

@renansaddam it still assumes having shared children matching the Rails defaults?, migrations, asset pipeline and more, so I'd vote yes. Which railsisms have you seen removed from upstream?

@renan

Disregard my last message in this case, I am not very familiar with Capistrano and Rails to be honest.
But my PHP application seems to be too much alike of an Rails app then as I removed railsless and didn't see a change.

Thanks!

@conatus

👍 to see this added. Thanks very much.

@rehevkor5

@leehambley Please accept.

Due to the code mentioned by medlefsen, I cannot bind an "after" callback to "deploy:symlink", forcing me to bind to "deploy:update_code" instead, incorrectly. As you can see, it also gives a deprecation notice.

@rehevkor5

Here's a workaround people can use in the meantime:

namespace :deploy do
  task :update do
    transaction do
      update_code
      create_symlink
    end
  end

  task :create_symlink, :except => { :no_release => true } do
    symlink
  end
end
@gido

👍 got problem for binding "after" callback.

  after "deploy:create_symlink", "myproject:custom_task"

even:

  after "deploy:symlink", "myproject:custom_task"
  # got a warning and my custom_task is not executed.

I suppose this PR will fix my issue, no?

@leehambley
@gido

@leehambley because of the hack mentionned by @medlefsen my callback after "deploy:symlink" or "deploy:create_symlink" is never executed.

if @snmaynard changes his pull request to reflect the fact that deploy:symlink throws a warning, and then call the original task, I'll merge it in a heartbeat!

I made this change in PR #14. I hope this is what you are expected.

@leehambley
@leehambley leehambley merged commit abfc24c into jeffbyrnes:master Apr 2, 2013
@leehambley
@gido

Thanks !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment