There is general dissatisfaction with the current state of things, but I don't think there is anything like a formal plan or probably even general agreement on how to fix things. My personal solution is going to be to build out the application resource as a replacement with hopefully fewer of the issues. I would definitely not be against yanking the deploy resource to a cookbook, and I know I've heard others express a desire to remove the pseudo-capistrano bits as most of it makes little sense in a config managed world. I think I'm over my quota on RFCs for the moment, but I would be glad to read one suggesting a path forward :-)
On Jan 9, 2015, at 3:20 AM, Roland Moriz < "> > wrote:
> Hi,
>
> the deploy resource and its provider [1] are very opinionated and tied to deployments of Ruby on Rails applications and modeled after the original Capistrano workflow defaults. But if you’re not deploying a Rails app, you’re pretty much out of luck.
> Because of its name and relevance („core resource“), many new chef users fall into this trap.
>
> Any plans to remove this from core chef w.g. with chef 13? A legacy_deploy cookbook could provide the current logic as HWRP.
>
> Another option would be to just remove the default provider and nest the current provider options below something, e.g.,
>
> ```
> Chef::Provider::Deploy::Rails
> Chef::Provider::Deploy::Rails::Branch
> Chef::Provider::Deploy::Rails::Revision
> Chef::Provider::Deploy::Rails::TimestampedDeploy
> ```
>
> What do you think?
--Noah
Archive powered by MHonArc 2.6.16.