Matt,
I think I see what you're saying. This seems like a pretty specific
use-case, though, so I'm not sure this fits in Capistrano. I think
your workaround is perfectly appropriate.
- Jamis
On Jun 22, 2008, at 6:11 PM, goodieboy wrote:
>
> Hi Jamis,
>
> I see what you mean about the pid file... I'll explain my scenario a
> little to help make sense of this. I have capistrano setup with a
> bunch of different projects. I also have a web app that is able to
> load/execute the tasks. I need the ability to lock out other
> "requests" to a task whether it's from the command line or from the
> web app, because having the same project worked on at the same time
> could definitely cause problems. I might be logged into the deployment
> box and executing a task, while a user is executing the same one from
> the web app.
>
> I've been creating a pid file using the before/after events but I
> wasn't feeling that it was a very sure way of doing it. So a few days
> ago I decided to use my own script that does exactly what "cap" does,
> except I added the pid file generation block as shown above.
>
> Does that make sense? Do you have any ideas on a better way I might
> achieve this?
>
> I'll see if I can whip up that logging patch.
>
> Thanks,
> Matt
>
> On Jun 22, 5:02 pm, Jamis Buck <[EMAIL PROTECTED]> wrote:
>> I'm not sure what value having cap provide a pidfile would do, since
>> cap isn't a daemon or server or otherwise meant to run in the
>> background. But I'd certainly be amenable to a patch to extend the
>> logging functionality, as you described.
>>
>> - Jamis
>>
>> On Jun 20, 2008, at 12:44 PM, goodieboy wrote:
>>
>>
>>
>>> Jamis,
>>
>>> I'm wondering if you'd consider adding pid file generation to the
>>> "cap" command? Something as simple as wrapping the
>>> Capistrano::CLI.execute call in a begin/rescue/ensure statement:
>>
>>> pid_file='./task.pid'
>>> begin
>>> File.open(pid_file, File::RDWR|File::CREAT){|f| f.puts $$}
>>> Capistrano::CLI.execute
>>> rescue
>>> puts $!
>>> ensure
>>> File.delete(pid_file)
>>> end
>>
>>> Maybe add it as an option to the "cap" command:
>>
>>> cap deploy -pid
>>
>>> Also, how about more logging options? Something I'd love to have
>>> is a
>>> log directory where the logs get stored in a ./log/<date>.<pid>
>>> file.
>>> That could be an option too? Maybe a task for deleting them all or
>>> by
>>> limit:
>>
>>> cap deploy -log
>>
>>> cap log:clear
>>
>>> And it'd be really cool if the file handle had sync=true so other
>>> apps
>>> could poll the log file while the cap logger was writing! :)
>>
>>> I'd gladly provide the code and tests if you'd like. Thanks for
>>> all of
>>> your efforts and awesome support!
>>
>>> Matt
> >
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
