-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
no_release server option disappeared in v3 #686
Comments
It should be possible to implement this using the
Combined with:
I'm not a massive fan of 'no_release', so if you can find something better then please do. Let me know if you need anything else, it would be nice to get this into 3.1.x |
Actually considering this further, I seem to recall that |
I believe there's already the opposite of filter, I think I called it |
@dunedain289 do you have any plans to implement this? I don't want to duplicate your efforts, but if not I'll probably look to pick this up on Friday |
Sorry about the close+reopen - today is not my day for using Github. I was looking through the code yesterday, trying to understand all the role and server selection flow, but didn't find an |
In order to provide a way for a server to perform tasks as part of a deploy but without being involved in the standard deploy flow, all included tasks will now prefer `release_roles` over `roles`. For example: on release_roles :all do # end This behaviour is implemented using `exclude`, a new option when selecting roles. `release_roles` is equivalent to: on roles :all, exclude: :no_release do # end Any server defined with `no_release: true` will be excluded from these tasks: server 'localhost', roles: %w{db}, no_release: true `exclude` can also be used in user defined tasks against any attribute, for example: server 'localhost', roles: %w{app web}, inactive: true on roles :app, exclude: :inactive do # end This commit resolves #686
@dunedain289 would you have some time to try out this feature branch?
|
@seenmyfate from my quick reading of that branch, it looks like exactly what we need. I may not get a chance to experiment until Monday or Tuesday, but I'll let you know my results when I can. |
Capistrano v2 understood the
:no_release => true
flag toserver
, allowing tasks to execute on other servers without performing the normal release flow on them as well.From my current reading of the v3 code, this is no longer the case. The use of
on roles :all
throughout the deploy flow blocks this behavior.Is this option, or similar flexibility, going to come back? My environment is probably unique for Rails/Capistrano deploys - we deploy to a shared NFS filesystem, which means only 1 host needs to update the code or run migrations, but many hosts need to execute other actions within our flow.
I'm willing to create a pull request to make this happen, but I'd like a little guidance on the maintainer's preferred plan here. My current best thought is to change the
blocks in the normal flow to something like:
along with adding
set :deploy_role, :all
to the default settings.The text was updated successfully, but these errors were encountered: