Hook between symlink files and symlink release

[FlxPeters]

I think we need one more hook between the symlink:shared task and the symlink:release task.

When you symlink something like the parameters.yml in a Symfony project, you need this when running the composer install command. But with the current hooks i can either call the command before symlinking (with missing parameters.yml) or after symlinking, but then i already have the new release as current.

When you have a look at the Capistrano flow, you will the there are two steps for symlinking: http://capistranorb.com/documentation/getting-started/flow/

deploy:updating
    git:create_release
    deploy:symlink:shared

deploy:publishing
    deploy:symlink:release

I think this is a much more flexible solution. What do you think? I can make a PR.

[cbrunnkvist]

Interesting. I might need this too. I'm in the process of breaking down project-specific Symfony playbook into something more modular & resuable (https://github.com/cbrunnkvist/ansistrano-symfony-deploy/).

[ricardclau]

This is an interesting one

In PHP, if you are using an OPCache with optimised production settings, you can safely run the Symfony cache regeneration after symlinking as everything will still be in the cache until you reload it (or you overflow it, but that's another problem) which you would do after cleanup

However, you may not have such settings (or not even be able to change them) and I am not sure about projects using Python or Ruby

It is certainly a bit more flexible and I cannot see any strong reasons against it.

Thoughts? @carlosbuenosvinos @theUniC @ajgarlag

And of course, PRs are welcome!

[ajgarlag]

Maybe we can simply move the symlinking of shared paths to the last position of update-code phase. The problem is that it could potentially break some playbooks and should be advertised as a BC break.

[cbrunnkvist]

As you say would introduce a backwards incompatibility.

A bigger issue for me (happens in the Symfony role I linked to above) is that I need to clear out the link targets after code update, but before linking takes place.

In addition, since there is no way to chain multiple _tasks_files, if my generic Symfony playbook hooks something up, the project-specific playbook applying the generic one cannot hook into the same e.g. after_update_code again without effectively canceling what the generic one needs... So the more hooks points, the merrier IMO.

[FlxPeters]

A bigger issue for me (happens in the Symfony role I linked to above) is that I need to clear out the link > targets after code update, but before linking takes place.

Thats a problem for me as well. What do you think about deleting all link targets by default?

[cbrunnkvist]

Yeah if it was done directly in Ansistrano then at least I wouldn't have to.

I am not sure I can think of any situation where this would not be the expected default behavior - I mean, you are after all explicitly specifying paths that you WANT to basically override and with shared...

(does not invalidate my point about the more hooks...)

[cbrunnkvist]

@ajgarlag You could in keep BC by doing the following:

1. start by canonically renaming the _symlink_ steps & hooks to _symlink_release_ -> we'd have _symlink_shared_ + _symlink_release_ which would be quite clear.
2. check if someone is still declaring the _symlink_ hook variable: in that case, assign (before|after)_symlink_release_ = (before|after)_symlink_ and link the shared stuff just before release step instead of after code update, thereby retaining legacy behavior.

Arguably, that's a bit complex a hack. I don't know how much you value backwards compatibility... :)

[ricardclau]

Hold on, sorry if I am not seeing it but would #50 break anything?

Otherwise 👍 on it