[Capistrano] Re: ANN: A new subversion SCM module
I've been thinking long and hard about this. It's definitely a move in the right direction, but I think it needs to be approached differently, which is why I haven't added this to trunk yet. My current thinking is this: sometime after the next release of capistrano (which will be Real Soon Now), I'd like to decouple the deployment method from the SCM. Currently, the two are too tightly coupled, which requires people to jump through lots of hoops to separate them. What I'm thinking is that each SCM module would simply become something that could be queried for the instructions needed to execute some task. For example, something like the following pseudo- code: svn = SCM::Subversion.new(config) p svn.checkout #- svn co -r1234 svn+ssh://foo.bar.com/svn/trunk / u/apps/foo/releases/12345 p svn.export #- svn export -r1234 svn+ssh://foo.bar.com/svn/ trunk /u/apps/foo/releases/12345 Then, the deployment method can be decoupled from the SCM: set :scm, :subversion # set :scm, :darcs # set :scm, :baz # etc. set :deploy_via, :checkout # set :deploy_via, :export # set :deploy_via, :copy # set :deploy_via, :rsync # etc. The important thing is to make sure a record is kept (consistently) on the server of what the currently deployed revision is, so that features like diff_from_last_deploy still work. I'll probably start working on that refactoring sometime after Christmas. - Jamis On Dec 6, 2006, at 10:52 PM, wolfmanjm wrote: I'd like to announce a new subversion SCM module for Capistrano. In addition to all the old functionality, it adds three new features. 1. Handles the subversion repository only being accessible from the local machine 2. Handles the subversion repository URL being different on local host and remote server 3. Handles different paths to svn binary on local host and remote server Details of this module can be read here: http://blog.wolfman.com/articles/2006/12/06/a-capistrano-scm-module- for-local-svn-access I will also upload the file to this group (if it allows me to). The file includes an extended subversion_test.rb for unit testing. This version is Beta, please test if you have a need for its functionality. Jamis... You are welcome to replace the current scm/subversion.rb with this one if you like (hint, hint ;) --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Re: ANN: A new subversion SCM module
sounds like a good idea, I look forward to seeing it. will you include a way to deploy when the scm is not accessible from the server? if not I'll be happy to implement that part, as I realize you don't need that use case. thanks On Dec 23, 11:42 am, Jamis Buck [EMAIL PROTECTED] wrote: I've been thinking long and hard about this. It's definitely a move in the right direction, but I think it needs to be approached differently, which is why I haven't added this to trunk yet. My current thinking is this: sometime after the next release of capistrano (which will be Real Soon Now), I'd like to decouple the deployment method from the SCM. Currently, the two are too tightly coupled, which requires people to jump through lots of hoops to separate them. What I'm thinking is that each SCM module would simply become something that could be queried for the instructions needed to execute some task. For example, something like the following pseudo- code: svn = SCM::Subversion.new(config) p svn.checkout #- svn co -r1234 svn+ssh://foo.bar.com/svn/trunk / u/apps/foo/releases/12345 p svn.export #- svn export -r1234 svn+ssh://foo.bar.com/svn/ trunk /u/apps/foo/releases/12345 Then, the deployment method can be decoupled from the SCM: set :scm, :subversion # set :scm, :darcs # set :scm, :baz # etc. set :deploy_via, :checkout # set :deploy_via, :export # set :deploy_via, :copy # set :deploy_via, :rsync # etc. The important thing is to make sure a record is kept (consistently) on the server of what the currently deployed revision is, so that features like diff_from_last_deploy still work. I'll probably start working on that refactoring sometime after Christmas. - Jamis On Dec 6, 2006, at 10:52 PM, wolfmanjm wrote: I'd like to announce a new subversion SCM module for Capistrano. In addition to all the old functionality, it adds three new features. 1. Handles the subversion repository only being accessible from the local machine 2. Handles the subversion repository URL being different on local host and remote server 3. Handles different paths to svn binary on local host and remote server Details of this module can be read here: http://blog.wolfman.com/articles/2006/12/06/a-capistrano-scm-module- for-local-svn-access I will also upload the file to this group (if it allows me to). The file includes an extended subversion_test.rb for unit testing. This version is Beta, please test if you have a need for its functionality. Jamis... You are welcome to replace the current scm/subversion.rb with this one if you like (hint, hint ;) --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Re: capistrano dotfile
will you be able to disable the stdout? right now mikes patch prints out a lot of stuff as it loads all the things in .caprc, which is kind of annoying. On Dec 23, 8:15 am, Jamis Buck [EMAIL PROTECTED] wrote: Mike, Alright, this finally made it in (as of revision 5774). I didn't use your implementation directly, though, as there were a few issues I had to think about. Here's how dotfiles work in edge capistrano: * The dotfile, by default, is called .caprc and will be searched for in your home directory. On Unices, this is the ENV[HOME] variable. On windows, it is #{ENV[HOMEDRIVE]}#{ENV[HOMEPATH]}. The environment is searched in that order (so if you have HOME set on Windows, it will be used), and if none is found the root directory is used. * You can override the path to the config file via the -c switch: cap -c /path/to/.customrc ... * You can specify that you don't want to use the config file at all via the -x switch: cap -x ... * The file will be loaded immediately after the -S options are processed. Thus, variables you set via -S will be available to the .caprc stuff. The major difference between the patch you submitted and the way I implemented it is that the .caprc will always be loaded, whether or not other recipe files are specified. (As I mentioned above, you can skip the config loading with -x.) Thanks for the idea, Mike, and sorry that took so long to get into trunk! - Jamis On Nov 21, 2006, at 6:02 AM, mbailey wrote: I'm loving capistrano. I'm using it for sysadmin tasks as well as rails deployment. I want to be free to use it from whichever directory I happen to be in and still have access to my favourite recipes. I want to be able to run commands on server groups that span projects. I want to use recipe gems that other developers may not have on their system so requiring them from a shared deploy.rb may not be appropriate. Below is a small patch that loads the contents of ~/.caprc before loading the default recipe file (usually config/deploy.rb). An example of my .caprc is below: # RECIPE GEMS - the easiest way I can think of to enable recipe gems require 'railsmachine/recipes' require 'deprec' # SSH OPTIONS - only set this once on workstation rather than on each project ssh_options[:keys] = %w(/Users/mbailey/.ssh/id_dsa) # ROLES - useful for getting cap shell on horizontal slice of systems # enables commands like this to span projects when not in a project dir: # export ROLES=scm cap -v shell role :scm, 'scm01', 'scm02', 'scm03' role :rails, 'r01', 'r02', 'r03', 'r04', 'r05' role :db, 'db01', 'db02', 'db03', 'db04' Does it look acceptable to go into Capistrano? The main benefit I could see is making it more convenient for users to run 'gem install recipename' and then update their ~/.caprc to make the recipes available. thanks, Mike inum:~/work/capistrano/lib/capistrano mbailey$ svn diff Index: cli.rb === --- cli.rb (revision 5603) +++ cli.rb (working copy) @@ -289,6 +289,10 @@ end def look_for_default_recipe_file! +# load overridable user defaults (if present) +if File.exist?(caprc = File.join(ENV['HOME'],'.caprc')) + @options[:recipes] caprc +end DEFAULT_RECIPES.each do |file| if File.exist?(file) @options[:recipes] file inum:~/work/capistrano/lib/capistrano mbailey$ rake test (in /Users/mbailey/work/capistrano) /usr/local/bin/ruby -Ilib -rubygems /usr/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/ rake_test_loader.rb test/actor_test.rb test/command_test.rb test/configuration_test.rb test/ssh_test.rb test/scm/cvs_test.rb test/scm/subversion_test.rb Loaded suite /usr/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/rake_test_loader Started .. .. Finished in 0.039947 seconds. 92 tests, 192 assertions, 0 failures, 0 errors --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Re: capistrano dotfile
Oh, and I should say: cap DOES have a -q flag, which suppresses all but the most significant output. By default, cap is noisy. cap -q some_task #- very quite cap -v some_task #- slightly noisier cap -vv some_task #- slightly noisier still cap -vvv some_task #- noisiest (default) - Jamis On Dec 23, 2006, at 4:33 PM, wolfmanjm wrote: sorry yes I can... here is an example whenI use deprec which uses caprc... Notice the 8 lines of output after loading caprc. It happens everytime, maybe there should be a -q that suppresses that although I like the rest of the output capistrano gives. loading configuration /usr/lib/ruby/gems/1.8/gems/capistrano-1.2.0/lib/capistrano/recipes/ standard.rb loading configuration /home/morris/.caprc loading configuration /usr/lib/ruby/gems/1.8/gems/deprec-1.1.0/lib/deprec/recipes/ssh.rb loading configuration /usr/lib/ruby/gems/1.8/gems/deprec-1.1.0/lib/deprec/recipes/svn.rb loading configuration /usr/lib/ruby/gems/1.8/gems/deprec-1.1.0/lib/deprec/recipes/ubuntu.rb loading configuration /usr/lib/ruby/gems/1.8/gems/deprec-1.1.0/lib/deprec/third_party/ mongrel_cluster/recipes.rb loading configuration /usr/lib/ruby/gems/1.8/gems/deprec-1.1.0/lib/deprec/third_party/ railsmachine/recipes/svn.rb loading configuration /usr/lib/ruby/gems/1.8/gems/deprec-1.1.0/lib/deprec/third_party/ railsmachine/recipes/apache.rb loading configuration /usr/lib/ruby/gems/1.8/gems/deprec-1.1.0/lib/deprec/third_party/ railsmachine/recipes/mysql.rb loading configuration /usr/lib/ruby/gems/1.8/gems/deprec-1.1.0/lib/deprec/recipes.rb loading configuration ./config/deploy.rb On Dec 23, 1:27 pm, Jamis Buck [EMAIL PROTECTED] wrote: On Dec 23, 2006, at 2:03 PM, wolfmanjm wrote: will you be able to disable the stdout? right now mikes patch prints out a lot of stuff as it loads all the things in .caprc, which is kind of annoying.I'm not sure what you mean? Mike's patch didn't really have anything special to do with writing diagnostic info. Can you be more specific? - Jamis On Dec 23, 8:15 am, Jamis Buck [EMAIL PROTECTED] wrote: Mike, Alright, this finally made it in (as of revision 5774). I didn't use your implementation directly, though, as there were a few issues I had to think about. Here's how dotfiles work in edge capistrano: * The dotfile, by default, is called .caprc and will be searched for in your home directory. On Unices, this is the ENV[HOME] variable. On windows, it is #{ENV[HOMEDRIVE]}#{ENV [HOMEPATH]}. The environment is searched in that order (so if you have HOME set on Windows, it will be used), and if none is found the root directory is used. * You can override the path to the config file via the -c switch: cap -c /path/to/.customrc ... * You can specify that you don't want to use the config file at all via the -x switch: cap -x ... * The file will be loaded immediately after the -S options are processed. Thus, variables you set via -S will be available to the .caprc stuff. The major difference between the patch you submitted and the way I implemented it is that the .caprc will always be loaded, whether or not other recipe files are specified. (As I mentioned above, you can skip the config loading with -x.) Thanks for the idea, Mike, and sorry that took so long to get into trunk! - Jamis On Nov 21, 2006, at 6:02 AM, mbailey wrote: I'm loving capistrano. I'm using it for sysadmin tasks as well as rails deployment. I want to be free to use it from whichever directory I happen to be in and still have access to my favourite recipes. I want to be able to run commands on server groups that span projects. I want to use recipe gems that other developers may not have on their system so requiring them from a shared deploy.rb may not be appropriate. Below is a small patch that loads the contents of ~/.caprc before loading the default recipe file (usually config/deploy.rb). An example of my .caprc is below: # RECIPE GEMS - the easiest way I can think of to enable recipe gems require 'railsmachine/recipes' require 'deprec' # SSH OPTIONS - only set this once on workstation rather than on each project ssh_options[:keys] = %w(/Users/mbailey/.ssh/id_dsa) # ROLES - useful for getting cap shell on horizontal slice of systems # enables commands like this to span projects when not in a project dir: # export ROLES=scm cap -v shell role :scm, 'scm01', 'scm02', 'scm03' role :rails, 'r01', 'r02', 'r03', 'r04', 'r05' role :db, 'db01', 'db02', 'db03', 'db04' Does it look acceptable to go into Capistrano? The main benefit I could see is making it more convenient for users to run 'gem install recipename' and then update their ~/.caprc to make the recipes available. thanks, Mike inum:~/work/capistrano/lib/capistrano mbailey$ svn diff Index: cli.rb
[Capistrano] [ANN] Capistrano 1.3.0
Here it is, Capistrano 1.3.0. Mostly it is just bug fixes, but it includes a few minor new features. The new features: * The sudo() method now supports an :as option, so that you can specify who the command should be executed as. This defaults to 'root'. * You can now encode the SSH user and port in the host specification, like: role :app, [EMAIL PROTECTED]:1234 * You can create a .caprc file in your home directory, which will be loaded on every cap invocation. The syntax for it is exactly the same as any other recipe file. This lets you specify common tasks and configuration across multiple projects. The significant miscellaneous fixes: * Make sure all assets in images, javascripts. and stylesheets directories are touched when code is deployed, so that the asset- timestamping feature in Rails works correctly. (Otherwise, the timestamps on the assets can be different on each host, which totally defeats the purpose.) * cap setup and checkouts use group-writable permissions for new directories and files * cap/rake integration is now deprecated. You should be using 'cap' directly, unless you write your own rake tasks. So, give it a whirl! Have a Merry Christmas, all. - Jamis --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---