From alexey.verkhovsky at gmail.com Thu Apr 24 19:28:06 2008 From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky) Date: Thu, 24 Apr 2008 17:28:06 -0600 Subject: [Cruisecontrolrb-developers] [ANN] CruiseControl.rb 1.3.0 Message-ID: <3945c4270804241628g692f6aaej8d66af975afd996e@mail.gmail.com> Dear all, CruiseControl.rb is a continuous integration tool. Its basic purpose in life is to alert members of a software project when one of them checks something into source control that breaks the build. CC.rb is easy to install, pleasant to use and simple to hack. It's written in Ruby. Version 1.3.0 is yet another small release, encompassing about 6 months of not-so-very-active ongoing development (keywords: simple, small, sweet). First and foremost, it's worth noticing that the default location of CC.rb configuration files and build data has changed to $HOME/.cruise (%USERPROFILE%\.cruise on Windows). As for the new features, release 1.3.0 has two: Build serialization: This is a way to ensure that CC.rb never runs more than one build at any given time. This helps to prevent conflicts between simultaneously running builds using the same resource (e.g., a database or a third-party service). To enable this, add "Configuration.serialize_builds = true; Configuration.serialized_build_timeout = 3.hours" to site_config.rb. Automatic purging of all builds: CC.rb uses the local file system for data storage. If there are several thousand build directories, this may noticeably slow down CC.rb dashboard. Now you can automatically tell it to purge old build directories. To enable this, add "BuildReaper.number_of_builds_to_keep = 200" to site_config.rb. In addition, there is an experimental plugin infrastructure (similar to Rails plugins). If you are writing CC.rb extensions, you may want to look at it. Start with "script/cruise_plugin list help". CHANGELOG - cruise data (build results, etc) is stored in $HOME/.cruise/ by default - builds can now be serialized - with a config option set, CC.rb will only run one build at a time - option to auto delete more than N builds - [experimental] plugins can be installed w/ script/cruise_plugin script - [bugfix] build requested status now stays on dashboard until a build starts - [patch] subversion external support - Nathan Wilmes - [patch] relative url support - Neal Clark LINKS Documentation: http://cruisecontrolrb.thoughtworks.com Downloads: http://rubyforge.org/frs/?group_id=2918 Bug tracker: http://jira.public.thoughtworks.org/browse/CCRB Users mailing list: cruisecontrolrb-users at rubyforge.org UPGRADE PROCEDURE IMPORTANT: as you saw above, the default location of CC.rb configuration and data changed from "wherever you extracted CruiseControl.rb sources" to $HOME/.cruise (%USERPROFILE%\.cruise on Windows). This can mess up your current setup, if it makes any assumptions about the location of those files, or if it runs CC.rb processes in an environment where $HOME is not a writable directory. 0. Consider not upgrading at all - in many cases, 1.3 adds no tangible value over 1.2.1. 1. Stop CC.rb if it's running. 2. Rename the directory containing the earlier CC.rb version (from now on referred as [cruise]) to something else (e.g., [cruise].old). 3. Make sure you don't have $HOME/.cruise directory yet. Remove it if you do. 4. Download CC.rb 1.3.0 from http://rubyforge.org/frs/?group_id=2918 5. Extract it to [cruise] directory. Make sure that you moved the earlier version away from [cruise] directory (step 2 above). 6. Copy [cruise].old/projects/ to [cruise]. Also copy [cruise].old/config/site_config.rb to [cruise]/config/site_config.rb. 7. If you run CC.rb in an environment where $HOME is not a writable directory, specify some other directory in CRUISE_DATA_ROOT, either by assigning it to CRUISE_DATA_ROOT constant in site_config.rb, or setting an OS environment variable of the same name before starting CC.rb. 8. Start CC.rb. The first time you start it, it should automatically move [cruise]/projects/ to $HOME/.cruise/. It will also copy site_config.rb to $HOME/.cruise/. FUTURE After this release we are: * migrating our RubyForge Subversion repository to Git (still on RubyForge), which will improve hackability by making it easier to maintain local branches. * migrating the bug tracker to LightHouse. This already happened, in fact. * making the version control interface pluggable, and implementing Mercurial and Git support out of the box - this functionality will be released in the next version - some time during the summer Happy cruising. -- Alexey Verkhovsky CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] RubyWorks [http://rubyworks.thoughtworks.com] From estebanm at opera.com Fri Apr 25 11:15:00 2008 From: estebanm at opera.com (=?utf-8?Q?Esteban_Manchado_Vel=C3=A1zquez?=) Date: Fri, 25 Apr 2008 17:15:00 +0200 Subject: [Cruisecontrolrb-developers] [ANN] CruiseControl.rb 1.3.0 In-Reply-To: <3945c4270804241628g692f6aaej8d66af975afd996e@mail.gmail.com> References: <3945c4270804241628g692f6aaej8d66af975afd996e@mail.gmail.com> Message-ID: On Fri, 25 Apr 2008 01:28:06 +0200, Alexey Verkhovsky wrote: > Version 1.3.0 is yet another small release, encompassing about 6 > months of not-so-very-active ongoing development (keywords: simple, > small, sweet). > [...] There seems to be a bug with command escaping: I have a complex test command that contains "&&", and the testrun gets executed twice :-( It all seems related to lib/command_line.rb, lines 118 to 124, where it says: stdout_prompt_command = options[:stdout] ? "echo #{escape("Platform.prompt} #{cmd} >> #{options[:stdout]} && " : '' stderr_prompt_command = options[:stderr] && options[:stderr] != options[:stdout] ? "echo #{Platform.prompt} #{cmd} >> #{options[:stderr]} && " : '' I think it should be: heading = escape("#{Platform.prompt} #{cmd}") stdout_prompt_command = options[:stdout] ? "echo #{heading} >> #{options[:stdout]} && " : '' stderr_prompt_command = options[:stderr] && options[:stderr] != options[:stdout] ? "echo #{heading} >> #{options[:stderr]} && " : '' That does the trick for me at least. -- Esteban Manchado Vel?zquez , who kind of likes internal builds (except M2, who ate his mail) From alexey.verkhovsky at gmail.com Mon Apr 28 16:54:33 2008 From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky) Date: Mon, 28 Apr 2008 14:54:33 -0600 Subject: [Cruisecontrolrb-developers] CC.rb trunk migrated to Git Message-ID: <3945c4270804281354u150cb67fw31de2cdd7dc56490@mail.gmail.com> Hi all, I have migrated CC.rb trunk to Git repository at RubyForge. Some cavets: 1. I'm not sure what happened with Subversion tags and branches. git-svnimport should have taken care of all that, but my git foo (all the 15 minutes worth of it) is not strong enough to find them there. 2. svn:externals are all gone. I don't think any of that is really important, cause our Subversion repository is still there, so anyone interested in archeology could still get to old tags and branches that way. Subversion trunk history is definitely visible in Git, and that is all I really care about. Basic source control workflow now looks as follows (anyone more familiar with Git, feel free to suggest better practices): 1. Set up your user name and email git config --global user.name "Your Name Comes Here" git config --global user.email you at yourdomain.example.com 2. Clone local repository from central repository Authenticated: git clone gitosis at rubyforge.org:cruisecontrolrb.git Public anonymous: git clone git://rubyforge.org/cruisecontrolrb.git As far as I understand what Tom Copeland (RubyForge admin) wrote, you'll have to upload your public SSH key to your RubyForge account, to get authenticated with Gitosis. 3. Make your changes. 4, Commit your changes to the local repository git add | rm | commit | et cetera 5., Synchronize with current repository git pull git fetch 6. If you are a committer, push them back on to the trunk: git push 7. If your don't have write access, create a patch git diff # apparently, Linux kernel uses git-format-patch instead, I don't know if we want that or not -- Alexey Verkhovsky CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] RubyWorks [http://rubyworks.thoughtworks.com] From alexey.verkhovsky at gmail.com Tue Apr 29 14:03:03 2008 From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky) Date: Tue, 29 Apr 2008 12:03:03 -0600 Subject: [Cruisecontrolrb-developers] Wonder if we can have a public repository on GitHub Message-ID: <3945c4270804291103u2c61ab1fn4790bc855e10a1fb@mail.gmail.com> Now that our source code is in Git, and bug tracker is in Lighthouse, I'm looking with envy at GitHub :) In this brave new distributed source control world, is it possible easy to have a GitHub Git repository tracking a RubyForge Git repository? Is it easy? -- Alexey Verkhovsky CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] RubyWorks [http://rubyworks.thoughtworks.com] From george at nutrun.com Tue Apr 29 14:10:31 2008 From: george at nutrun.com (George Malamidis) Date: Tue, 29 Apr 2008 19:10:31 +0100 Subject: [Cruisecontrolrb-developers] Wonder if we can have a public repository on GitHub In-Reply-To: <3945c4270804291103u2c61ab1fn4790bc855e10a1fb@mail.gmail.com> References: <3945c4270804291103u2c61ab1fn4790bc855e10a1fb@mail.gmail.com> Message-ID: Does this look relevant to what you have in mind? http://gems.github.com/ Thanks, George On 29 Apr 2008, at 19:03, Alexey Verkhovsky wrote: > Now that our source code is in Git, and bug tracker is in Lighthouse, > I'm looking with envy at GitHub :) > In this brave new distributed source control world, is it possible > easy to have a GitHub Git repository tracking a RubyForge Git > repository? Is it easy? > > -- > Alexey Verkhovsky > CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] > RubyWorks [http://rubyworks.thoughtworks.com] > _______________________________________________ > Cruisecontrolrb-developers mailing list > Cruisecontrolrb-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers From alexey.verkhovsky at gmail.com Tue Apr 29 15:36:06 2008 From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky) Date: Tue, 29 Apr 2008 13:36:06 -0600 Subject: [Cruisecontrolrb-developers] Wonder if we can have a public repository on GitHub In-Reply-To: References: <3945c4270804291103u2c61ab1fn4790bc855e10a1fb@mail.gmail.com> Message-ID: <3945c4270804291236g3d0040caraab6a7bc0a3d5358@mail.gmail.com> On Tue, Apr 29, 2008 at 12:10 PM, George Malamidis wrote: > Does this look relevant to what you have in mind? > http://gems.github.com/ Nope, doesn't look like it. What I have in mind is to have a GitHub repo automatically track the RubyForge repo, so that we could use GutHub browser, but keep the central repo on RubyForge. Either with a post-commit hook on RubyForge end or (better) with some setting on GitHub repo. -- Alex P.S. We could, of course, just move the central repository to GitHub, but I volunteered CC.rb to be a guinea pig for RubyForge Git support. From thewoolleyman at gmail.com Tue Apr 29 15:56:10 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 29 Apr 2008 12:56:10 -0700 Subject: [Cruisecontrolrb-developers] Wonder if we can have a public repository on GitHub In-Reply-To: <3945c4270804291236g3d0040caraab6a7bc0a3d5358@mail.gmail.com> References: <3945c4270804291103u2c61ab1fn4790bc855e10a1fb@mail.gmail.com> <3945c4270804291236g3d0040caraab6a7bc0a3d5358@mail.gmail.com> Message-ID: On Tue, Apr 29, 2008 at 12:36 PM, Alexey Verkhovsky wrote: > What I have in mind is to have a GitHub repo automatically track the > RubyForge repo, so that we could use GutHub browser, but keep the > central repo on RubyForge. Either with a post-commit hook on RubyForge > end or (better) with some setting on GitHub repo. You have to pick one as the "master" repo, AFAIK. If you want to have this be rubyforge, then you can't have the commit triggering happen on rubyforge. It would have to be triggered by somehow observing activity on github. Whether that happens on rubyforge or github probably doesn't matter, as long as the correct command is executed (via ssh or some github API?) > P.S. We could, of course, just move the central repository to GitHub, > but I volunteered CC.rb to be a guinea pig for RubyForge Git support. If you really like github's support better, I'd say make that the master repository, and just deprecate the rubyforge repo (delete everything except a readme file with a pointer to github). Anything else would essentially be having a master, and a mirror of the master, which just seems too confusing to be worth it, regardless of which is the master and which is the mirror.