[chef-dev] Re: Re: file deploy resource

[Jesse Campbell < >]

Is the objection here because of the provider attribute named "scm_provider", and the source named "repo"?

Other than the naming, all the deploy provider does is maintain multiple versions, with a "current" pointed to the active one. This is just like capistrano, which doesn't have the silly requirement that you store all your stuff in a git or svn repository.

What would make this not "feel wrong"?

On Mon, Feb 25, 2013 at 5:20 PM, Juanje Ojeda Croissier < " target="_blank"> > wrote:

Actually, I've been thinking the same from some time ago. Deploy
resource should deploy apps, doesn't matter if they come from a SCM,
from artifact, file...
I agree that to have a SCM provider that is not SCM at all, feels just
wrong, but maybe the problem is that it shouldn't accept just SCM
providers. Maybe others like artifacts and archives.

On Mon, Feb 25, 2013 at 9:52 PM, Joseph Holsten
< "> > wrote:
> the deploy resource is deeply tied to the scm providers. It is designed to deploy and app from an scm. It is not designed to deploy from artifacts (cf artifact cookbook) or archives (cf ark cookbook) or native packages.
>
> It would be nice to have all the application cookbook's callbacks wrapped around those ways of dropping files in place tho. This makes me wonder if perhaps the deploy resource should go away, and that tooling should be pulled up into application. Or similar.
>
>
> On 2013-02-25, at 13:02, Jesse Campbell < "> > wrote:
>
>> It does look a little similar to the artifact cookbook...
>> I was just hoping I'd only have to teach the guys in my group one way of deploying (we went with application / application_php / application_java / application_python)...
>> so we'd have to learn yet another new and different way to accomplish the same task. boo.
>>
>> What is the original intention of the deploy resource? I thought it was for deploying an app :D
>>
>>
>> On Mon, Feb 25, 2013 at 3:30 PM, AJ Christensen < "> > wrote:
>> It doesn't feel right to overload the deploy resource with
>> functionality that doesn't really reflect it's original intention (or
>> any of the existing providers), but I see where you are coming from. I
>> could have sworn I saw someone trying to hack this into remote_file a
>> few weeks ago on this list.
>>
>> I believe this is similar to RiotGames' Artifact style deployments
>> (?), which can deploy from Nexus as well? [0]
>>
>> --AJ
>>
>> [0] https://github.com/RiotGames/artifact-cookbook
>>
>> On 26 February 2013 09:24, Cassiano Leal < "> > wrote:
>> > It makes perfect sense to me. Capistrano has that, and it's super useful for
>> > compiled binaries.
>> >
>> > Thanks for bringing this capability to Chef's deploy resource.
>> >
>> > - cassiano
>> >
>> > On Monday, February 25, 2013 at 17:20, Jesse Campbell wrote:
>> >
>> > Not quite enough words there to convey your meaning clearly, but I'll guess
>> > that what you are saying is that a remote file is not an SCM resource, so I
>> > shouldn't do this?
>> >
>> > Explain further. What are you getting at?
>> >
>> > I want to be able to use "deploy" (and by extension "application" and
>> > "application_*") without having a git target because the application is a
>> > war stored on an FTP server, the application is in a zip file downloaded
>> > from a web server, the application is in a zip stored on a network drive.
>> >
>> >
>> > On Mon, Feb 25, 2013 at 2:46 PM, AJ Christensen < "> > wrote:
>> >
>> > This isn't an SCM (at all). Wat?
>> >
>> > --AJ
>> >
>> > On 26 February 2013 06:38, Jesse Campbell < "> > wrote:
>> >> and here, solving CHEF-2506 and COOK-2444, I moved the etag and
>> >> last-modified header checks to the base remote_file provider
>> >>
>> >>
>> >> https://github.com/jcam/chef/compare/rest_client_11...jcam:remote_file_deploy
>> >>
>> >> I'll put together a bug and pull request once i write some unit tests
>> >>
>> >>
>> >> On Mon, Feb 25, 2013 at 9:14 AM, Jesse Campbell < "> > wrote:
>> >>>
>> >>> ... and here, updated with support for etag and last-modified headers
>> >>>
>> >>>
>> >>>
>> >>> https://github.com/jcam/chef/blob/remote_file_deploy/lib/chef/provider/remote_file/deploy.rb
>> >>>
>> >>>
>> >>> On Mon, Feb 25, 2013 at 7:26 AM, Jesse Campbell < "> > wrote:
>> >>>>
>> >>>> In this commit
>> >>>>
>> >>>> https://github.com/jcam/chef/commit/a7f5599c669c840c98945a97d3d00644da00d30a
>> >>>> I added a remote file deploy, which allows using the deploy resource
>> >>>> like
>> >>>> this:
>> >>>>
>> >>>> deploy_revision "/tmp/hdocs" do
>> >>>>   repo "https://www.google.com/images/srpr/logo3w.png"
>> >>>>   revision "a123b456c789"
>> >>>>   scm_provider Chef::Provider::RemoteFile::Deploy
>> >>>>   symlink_before_migrate Hash.new
>> >>>>   migrate false
>> >>>> end
>> >>>>
>> >>>> Does this belong as remote_file/deploy.rb, or as deploy/remote_file.rb,
>> >>>> or should this be inside a recipe? This would replace the current
>> >>>> java_remote_file in the application_java cookbook.
>> >>>
>> >>>
>> >>
>> >
>> >
>> >
>>
>

--
Juanje

http://about.me/juanje