Skip to content
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

Closed
dunedain289 opened this issue Oct 11, 2013 · 7 comments
Closed

no_release server option disappeared in v3 #686

dunedain289 opened this issue Oct 11, 2013 · 7 comments
Milestone

Comments

@dunedain289
Copy link

Capistrano v2 understood the :no_release => true flag to server, 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

on roles :all do
  ...
end

blocks in the normal flow to something like:

on roles fetch(:deploy_role) do
  ...
end

along with adding set :deploy_role, :all to the default settings.

@seenmyfate
Copy link
Member

It should be possible to implement this using the filter option - so for example:

on roles :all, filter: :no_release do
  # 
end

Combined with:

role :nfs, %w{vagrant@localhost} no_release: true

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

@seenmyfate
Copy link
Member

Actually considering this further, I seem to recall that filter is actually an alias for select, meaning that this is actually the opposite of what you would need here - maybe we need to implement an except option, or alternatively just set a default option to all servers of release: true and then explicitly set release: false for the servers that don't require the code. That way maybe on roles :all, select: :release might read a little better.

@leehambley
Copy link
Member

I believe there's already the opposite of filter, I think I called it exclude. But you'd have to check the code. (At least I recall planning to implement it)

@seenmyfate
Copy link
Member

@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

@dunedain289
Copy link
Author

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 exclude option. I also didn't quite grok that flow well enough to make major changes, so if you have a game plan here, I'll gladly defer to you.

seenmyfate added a commit that referenced this issue Oct 18, 2013
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
@seenmyfate
Copy link
Member

@dunedain289 would you have some time to try out this feature branch?

 gem 'capistrano', github: 'capistrano/capistrano', branch: 'feature/no-release'

@dunedain289
Copy link
Author

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

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

No branches or pull requests

3 participants