From eric.hanchrow at gmail.com Mon Apr 21 16:20:04 2008 From: eric.hanchrow at gmail.com (Eric Hanchrow) Date: Mon, 21 Apr 2008 13:20:04 -0700 Subject: [Cruisecontrolrb-users] Is CruiseControl.rb for me? Message-ID: <36366a980804211320v1e36a7dcu47d106d4f6be6c01@mail.gmail.com> Naturally I want some sort of continuous integration system. But what makes my situation unusual is that what I want to build is structured in an unusual way, and it's not clear to me if CruiseControl.rb can gracefully handle that structure. I want to independently build half a dozen "projects", each of which (in CruiseControl.NET terms) is its own "queue". Each corresponds to one deliverable set of files. (One project represents our web site; another represents a Windows installer that we build ... etc). Now, those projects don't simply correspond to a single Subversion URL; instead, each is composed of a number of "kits", each of which has its own Subversion URL. We have about 50 separate kits; most are basically a bunch of C-sharp files and a .csproj file. Each kit typically depends on some others; the kits thus form a directed acyclic graph of dependencies. We have a tool that will build a kit, and all its dependencies; and will also check them out of Subversion if needed. I wrote this tool myself and am perfectly comfortable hacking it. For each project, I want CruiseControl.rb to monitor the bits of the subversion repository that correspond to the constituent kits, and trigger a build whenever anything changes in those bits. Note that this is not the same as monitoring the entire repository, since I don't want a change in an unrelated kit to trigger a build for this project; nor is it the same as monitoring just one kit, since the project depends on many kits. Our building tool already knows how to determine whether a kit needs to be updated, so I'm imagining that CruiseControl.rb would simply invoke the build tool as a subprocess. At first I thought I would be able to teach it to do this by suitable fiddling of the "SourceControl" class, but I quickly confused myself -- partly because I haven't yet figured out how CruiseControl.rb works, and partly because I barely know the fundamentals of Ruby. I also have a very vague suspicion that, fundamentally, CruiseControl.rb assumes that there's a one-to-one-to-one correspondence between projects, Subversion URLs, and working copies; and that I'd need to change that assumption in order to get things working the way I want. Anyway: does sound doable -- for someone who's a decent programmer but new to Ruby -- and if so, do you have any advice on how to start? From bkimble at inc21.com Mon Apr 21 16:28:05 2008 From: bkimble at inc21.com (Billy Kimble) Date: Mon, 21 Apr 2008 13:28:05 -0700 Subject: [Cruisecontrolrb-users] Is CruiseControl.rb for me? In-Reply-To: <36366a980804211320v1e36a7dcu47d106d4f6be6c01@mail.gmail.com> References: <36366a980804211320v1e36a7dcu47d106d4f6be6c01@mail.gmail.com> Message-ID: You can probably use SVN externals to achieve what you want :) Structure: /project -> http://yourdomain.com/svn/project /lib -> SVN External pointing to http://yourdomain.com/svn/kits/lib201 /config -> SVN External pointing to http://yourdomain.com/svn/kits/ config991 /docs -> SVN External pointing to http://yourdomain.com/svn/kits/ docs2093 In this scenario, if you add http://yourdomain.com/svn/project to CC, it will trigger any time anything in ANY of the kits is committed. If you add just the kit's svn repository location to CC, it will only trigger for that particular kit. Does this help? Tag a kit and just add that kit to the repository, or On Apr 21, 2008, at 1:20 PM, Eric Hanchrow wrote: > Naturally I want some sort of continuous integration system. But what > makes my situation unusual is that what I want to build is structured > in an unusual way, and it's not clear to me if CruiseControl.rb can > gracefully handle that structure. > > I want to independently build half a dozen "projects", each of which > (in CruiseControl.NET terms) is its own "queue". Each corresponds to > one deliverable set of files. (One project represents our web site; > another represents a Windows installer that we build ... etc). Now, > those projects don't simply correspond to a single Subversion URL; > instead, each is composed of a number of "kits", each of which has its > own Subversion URL. We have about 50 separate kits; most are > basically a bunch of C-sharp files and a .csproj file. Each kit > typically depends on some others; the kits thus form a directed > acyclic graph of dependencies. We have a tool that will build a kit, > and all its dependencies; and will also check them out of Subversion > if needed. I wrote this tool myself and am perfectly comfortable > hacking it. > > For each project, I want CruiseControl.rb to monitor the bits of the > subversion repository that correspond to the constituent kits, and > trigger a build whenever anything changes in those bits. Note that > this is not the same as monitoring the entire repository, since I > don't want a change in an unrelated kit to trigger a build for this > project; nor is it the same as monitoring just one kit, since the > project depends on many kits. Our building tool already knows how to > determine whether a kit needs to be updated, so I'm imagining that > CruiseControl.rb would simply invoke the build tool as a subprocess. > > At first I thought I would be able to teach it to do this by suitable > fiddling of the "SourceControl" class, but I quickly confused myself > -- partly because I haven't yet figured out how CruiseControl.rb > works, and partly because I barely know the fundamentals of Ruby. > > I also have a very vague suspicion that, fundamentally, > CruiseControl.rb assumes that there's a one-to-one-to-one > correspondence between projects, Subversion URLs, and working copies; > and that I'd need to change that assumption in order to get things > working the way I want. > > Anyway: does sound doable -- for someone who's a decent programmer but > new to Ruby -- and if so, do you have any advice on how to start? > _______________________________________________ > Cruisecontrolrb-users mailing list > Cruisecontrolrb-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From eric.hanchrow at gmail.com Mon Apr 21 16:32:00 2008 From: eric.hanchrow at gmail.com (Eric Hanchrow) Date: Mon, 21 Apr 2008 13:32:00 -0700 Subject: [Cruisecontrolrb-users] Is CruiseControl.rb for me? In-Reply-To: References: <36366a980804211320v1e36a7dcu47d106d4f6be6c01@mail.gmail.com> Message-ID: <36366a980804211332l1436b583o1b3127b54c0bffa9@mail.gmail.com> Thanks for the quick response, but I don't think externals will work, because I don't want to change the structure of our source tree; doing so would force the developers to change the way they work, and one of my goals is to avoid that. On Mon, Apr 21, 2008 at 1:28 PM, Billy Kimble wrote: > You can probably use SVN externals to achieve what you want :) > > Structure: > > /project -> http://yourdomain.com/svn/project > /lib -> SVN External pointing to http://yourdomain.com/svn/kits/lib201 > /config -> SVN External pointing to http://yourdomain.com/svn/kits/ > config991 > /docs -> SVN External pointing to http://yourdomain.com/svn/kits/ > docs2093 > > > In this scenario, if you add http://yourdomain.com/svn/project to > CC, it will trigger any time anything in ANY of the kits is > committed. If you add just the kit's svn repository location to CC, > it will only trigger for that particular kit. > > Does this help? > > Tag a kit and just add that kit to the repository, or > > > On Apr 21, 2008, at 1:20 PM, Eric Hanchrow wrote: > > > Naturally I want some sort of continuous integration system. But what > > makes my situation unusual is that what I want to build is structured > > in an unusual way, and it's not clear to me if CruiseControl.rb can > > gracefully handle that structure. > > > > I want to independently build half a dozen "projects", each of which > > (in CruiseControl.NET terms) is its own "queue". Each corresponds to > > one deliverable set of files. (One project represents our web site; > > another represents a Windows installer that we build ... etc). Now, > > those projects don't simply correspond to a single Subversion URL; > > instead, each is composed of a number of "kits", each of which has its > > own Subversion URL. We have about 50 separate kits; most are > > basically a bunch of C-sharp files and a .csproj file. Each kit > > typically depends on some others; the kits thus form a directed > > acyclic graph of dependencies. We have a tool that will build a kit, > > and all its dependencies; and will also check them out of Subversion > > if needed. I wrote this tool myself and am perfectly comfortable > > hacking it. > > > > For each project, I want CruiseControl.rb to monitor the bits of the > > subversion repository that correspond to the constituent kits, and > > trigger a build whenever anything changes in those bits. Note that > > this is not the same as monitoring the entire repository, since I > > don't want a change in an unrelated kit to trigger a build for this > > project; nor is it the same as monitoring just one kit, since the > > project depends on many kits. Our building tool already knows how to > > determine whether a kit needs to be updated, so I'm imagining that > > CruiseControl.rb would simply invoke the build tool as a subprocess. > > > > At first I thought I would be able to teach it to do this by suitable > > fiddling of the "SourceControl" class, but I quickly confused myself > > -- partly because I haven't yet figured out how CruiseControl.rb > > works, and partly because I barely know the fundamentals of Ruby. > > > > I also have a very vague suspicion that, fundamentally, > > CruiseControl.rb assumes that there's a one-to-one-to-one > > correspondence between projects, Subversion URLs, and working copies; > > and that I'd need to change that assumption in order to get things > > working the way I want. > > > > Anyway: does sound doable -- for someone who's a decent programmer but > > new to Ruby -- and if so, do you have any advice on how to start? > > _______________________________________________ > > Cruisecontrolrb-users mailing list > > Cruisecontrolrb-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > > > > -- > > This message has been scanned for viruses and > > dangerous content by MailScanner, and is > > believed to be clean. > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > Cruisecontrolrb-users mailing list > Cruisecontrolrb-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > From denis at haskinferguson.net Mon Apr 21 16:32:50 2008 From: denis at haskinferguson.net (Denis Haskin) Date: Mon, 21 Apr 2008 16:32:50 -0400 Subject: [Cruisecontrolrb-users] Fail build on code coverage level? Message-ID: <480CF9F2.6090009@haskinferguson.net> I've got rcov_rails as part of my continuous integration build, mainly thanks to [1] (edited it slightly to add a dependency db:test:prepare as the cruisecontrol.rb doc suggests. Can someone point me in the right direction to what I should do to make the code coverage level a criteria for a successful build? E.g. if code coverage is < 80% (or maybe even <80% for a given source file) then the build should fail; otherwise succeed (assuming the build+test itself suceed). Thoughts? Thanks -- dwh [1] http://deadprogrammersociety.blogspot.com/2007/06/cruisecontrolrb-and-rcov-are-so-good.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080421/dcdfded6/attachment.html From bwnoll at gmail.com Mon Apr 21 16:39:03 2008 From: bwnoll at gmail.com (Bryan Noll) Date: Mon, 21 Apr 2008 14:39:03 -0600 Subject: [Cruisecontrolrb-users] Fail build on code coverage level? In-Reply-To: <480CF9F2.6090009@haskinferguson.net> References: <480CF9F2.6090009@haskinferguson.net> Message-ID: <480CFB67.2020609@gmail.com> Couldn't you just check in a test that runs `rcov blah ...` somewhere and then parses through the results, checking for the percentage value you're interested in. If said percentage value is less than X... assert(false, "You don't have enough tests!") Denis Haskin wrote: > I've got rcov_rails as part of my continuous integration build, mainly > thanks to [1] (edited it slightly to add a dependency db:test:prepare as > the cruisecontrol.rb doc suggests. > > Can someone point me in the right direction to what I should do to make > the code coverage level a criteria for a successful build? E.g. if code > coverage is < 80% (or maybe even <80% for a given source file) then the > build should fail; otherwise succeed (assuming the build+test itself > suceed). > > Thoughts? > > Thanks -- dwh > > [1] > http://deadprogrammersociety.blogspot.com/2007/06/cruisecontrolrb-and-rcov-are-so-good.html > > > ------------------------------------------------------------------------ > > _______________________________________________ > Cruisecontrolrb-users mailing list > Cruisecontrolrb-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users From jeremystellsmith at gmail.com Mon Apr 21 19:10:26 2008 From: jeremystellsmith at gmail.com (Jeremy Stell-Smith) Date: Mon, 21 Apr 2008 16:10:26 -0700 Subject: [Cruisecontrolrb-users] Is CruiseControl.rb for me? In-Reply-To: <36366a980804211332l1436b583o1b3127b54c0bffa9@mail.gmail.com> References: <36366a980804211320v1e36a7dcu47d106d4f6be6c01@mail.gmail.com> <36366a980804211332l1436b583o1b3127b54c0bffa9@mail.gmail.com> Message-ID: You definitely can achieve what you want, using build triggers. Each "kit" would be a project for cruise, and you can tell each project which projects trigger it - check the docs for info. However, you might run into a wall with 50 projects on the same cruise box. Each of our projects runs as a separate process, and not only that, each process has the rails runtime loaded. This means that for 50 projects, you are looking at a lot of memory. If you want to try it anyway, be sure to turn on serialized builds in your site.config. If you look around and determine that nothing does quite what you want it to, I will say that ccrb is much more hackable than most. That said you might go faster in a language that you're comfortable with. On Mon, Apr 21, 2008 at 1:32 PM, Eric Hanchrow wrote: > Thanks for the quick response, but I don't think externals will work, > because I don't want to change the structure of our source tree; doing > so would force the developers to change the way they work, and one of > my goals is to avoid that. > > On Mon, Apr 21, 2008 at 1:28 PM, Billy Kimble wrote: > > You can probably use SVN externals to achieve what you want :) > > > > Structure: > > > > /project -> http://yourdomain.com/svn/project > > /lib -> SVN External pointing to > http://yourdomain.com/svn/kits/lib201 > > /config -> SVN External pointing to > http://yourdomain.com/svn/kits/ > > config991 > > /docs -> SVN External pointing to > http://yourdomain.com/svn/kits/ > > docs2093 > > > > > > In this scenario, if you add http://yourdomain.com/svn/project to > > CC, it will trigger any time anything in ANY of the kits is > > committed. If you add just the kit's svn repository location to CC, > > it will only trigger for that particular kit. > > > > Does this help? > > > > Tag a kit and just add that kit to the repository, or > > > > > > On Apr 21, 2008, at 1:20 PM, Eric Hanchrow wrote: > > > > > Naturally I want some sort of continuous integration system. But > what > > > makes my situation unusual is that what I want to build is structured > > > in an unusual way, and it's not clear to me if CruiseControl.rb can > > > gracefully handle that structure. > > > > > > I want to independently build half a dozen "projects", each of which > > > (in CruiseControl.NET terms) is its own "queue". Each corresponds to > > > one deliverable set of files. (One project represents our web site; > > > another represents a Windows installer that we build ... etc). Now, > > > those projects don't simply correspond to a single Subversion URL; > > > instead, each is composed of a number of "kits", each of which has > its > > > own Subversion URL. We have about 50 separate kits; most are > > > basically a bunch of C-sharp files and a .csproj file. Each kit > > > typically depends on some others; the kits thus form a directed > > > acyclic graph of dependencies. We have a tool that will build a kit, > > > and all its dependencies; and will also check them out of Subversion > > > if needed. I wrote this tool myself and am perfectly comfortable > > > hacking it. > > > > > > For each project, I want CruiseControl.rb to monitor the bits of the > > > subversion repository that correspond to the constituent kits, and > > > trigger a build whenever anything changes in those bits. Note that > > > this is not the same as monitoring the entire repository, since I > > > don't want a change in an unrelated kit to trigger a build for this > > > project; nor is it the same as monitoring just one kit, since the > > > project depends on many kits. Our building tool already knows how to > > > determine whether a kit needs to be updated, so I'm imagining that > > > CruiseControl.rb would simply invoke the build tool as a subprocess. > > > > > > At first I thought I would be able to teach it to do this by suitable > > > fiddling of the "SourceControl" class, but I quickly confused myself > > > -- partly because I haven't yet figured out how CruiseControl.rb > > > works, and partly because I barely know the fundamentals of Ruby. > > > > > > I also have a very vague suspicion that, fundamentally, > > > CruiseControl.rb assumes that there's a one-to-one-to-one > > > correspondence between projects, Subversion URLs, and working copies; > > > and that I'd need to change that assumption in order to get things > > > working the way I want. > > > > > > Anyway: does sound doable -- for someone who's a decent programmer > but > > > new to Ruby -- and if so, do you have any advice on how to start? > > > _______________________________________________ > > > Cruisecontrolrb-users mailing list > > > Cruisecontrolrb-users at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > > > > > > -- > > > This message has been scanned for viruses and > > > dangerous content by MailScanner, and is > > > believed to be clean. > > > > > > -- > > This message has been scanned for viruses and > > dangerous content by MailScanner, and is > > believed to be clean. > > > > _______________________________________________ > > Cruisecontrolrb-users mailing list > > Cruisecontrolrb-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > > > _______________________________________________ > Cruisecontrolrb-users mailing list > Cruisecontrolrb-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080421/95014c03/attachment-0001.html From thewoolleyman at gmail.com Mon Apr 21 21:37:55 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 21 Apr 2008 18:37:55 -0700 Subject: [Cruisecontrolrb-users] Fail build on code coverage level? In-Reply-To: <480CFB67.2020609@gmail.com> References: <480CF9F2.6090009@haskinferguson.net> <480CFB67.2020609@gmail.com> Message-ID: On Mon, Apr 21, 2008 at 1:39 PM, Bryan Noll wrote: > Couldn't you just check in a test that runs `rcov blah ...` somewhere > and then parses through the results, checking for the percentage value > you're interested in. > > If said percentage value is less than X... assert(false, "You don't have > enough tests!") Or run this test (or something that just raises an exception if coverage is low) only as part of a separate rake task, which runs after your rcov task (both called from default cruise task) -- Chad From thewoolleyman at gmail.com Mon Apr 21 21:47:51 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 21 Apr 2008 18:47:51 -0700 Subject: [Cruisecontrolrb-users] Is CruiseControl.rb for me? In-Reply-To: <36366a980804211332l1436b583o1b3127b54c0bffa9@mail.gmail.com> References: <36366a980804211320v1e36a7dcu47d106d4f6be6c01@mail.gmail.com> <36366a980804211332l1436b583o1b3127b54c0bffa9@mail.gmail.com> Message-ID: On Mon, Apr 21, 2008 at 1:32 PM, Eric Hanchrow wrote: > Thanks for the quick response, but I don't think externals will work, > because I don't want to change the structure of our source tree; doing > so would force the developers to change the way they work, and one of > my goals is to avoid that. As Jeremy said, you may try build triggers. If that doesn't work, I think svn:externals could definitely work. We've put a lot of effort into making sure externals are detected and reported properly in change detection and changeset reporting, and I think trunk works mostly pretty well in this area :) As for having to change the source tree, how about this: You can have a separate project, which is only used to build your "kit". This project is composed of only externals, which arrange things in the proper way to achive a build (perhaps with some hacks to your build process). Your developers can use the regular repo locations the way they normally do, this separate project that ties everything together via externals will only be used by cruise.rb. Just an idea, let us know if you get it working. -- Chad From denis at haskinferguson.net Tue Apr 22 09:37:17 2008 From: denis at haskinferguson.net (Denis Haskin) Date: Tue, 22 Apr 2008 09:37:17 -0400 Subject: [Cruisecontrolrb-users] Fail build on code coverage level? In-Reply-To: References: <480CF9F2.6090009@haskinferguson.net> <480CFB67.2020609@gmail.com> Message-ID: <480DEA0D.4000000@haskinferguson.net> Thanks to you both -- I'll give that a shot today. dwh Chad Woolley wrote: > On Mon, Apr 21, 2008 at 1:39 PM, Bryan Noll wrote: > >> Couldn't you just check in a test that runs `rcov blah ...` somewhere >> and then parses through the results, checking for the percentage value >> you're interested in. >> >> If said percentage value is less than X... assert(false, "You don't have >> enough tests!") >> > > Or run this test (or something that just raises an exception if > coverage is low) only as part of a separate rake task, which runs > after your rcov task (both called from default cruise task) > > -- Chad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080422/9194da19/attachment.html From tim.harding at gmail.com Tue Apr 22 11:06:20 2008 From: tim.harding at gmail.com (Tim Harding) Date: Tue, 22 Apr 2008 16:06:20 +0100 Subject: [Cruisecontrolrb-users] Fail build on code coverage level? In-Reply-To: <480DEA0D.4000000@haskinferguson.net> References: <480CF9F2.6090009@haskinferguson.net> <480CFB67.2020609@gmail.com> <480DEA0D.4000000@haskinferguson.net> Message-ID: Just found this: "The answer is vl_cruise_control, a Rails plugin that uses rcov to enforce a coverage target, and causes CC.rb to mark a build as failed if that target isn't met. So in addition to regularly checking that all the tests pass, we also check that all (or substantially all) of our code is accounted for in our tests. " Here: http://www.viget.com/extend/tools-of-the-trade-vl-cruise-control/ That looks like a really nice way of doing what you want... haven't tried it. On Tue, Apr 22, 2008 at 2:37 PM, Denis Haskin wrote: > Thanks to you both -- I'll give that a shot today. > > dwh > > Chad Woolley wrote: > > On Mon, Apr 21, 2008 at 1:39 PM, Bryan Noll wrote: > > > Couldn't you just check in a test that runs `rcov blah ...` somewhere > and then parses through the results, checking for the percentage value > you're interested in. > > If said percentage value is less than X... assert(false, "You don't have > enough tests!") > > > Or run this test (or something that just raises an exception if > coverage is low) only as part of a separate rake task, which runs > after your rcov task (both called from default cruise task) > > -- Chad > > > _______________________________________________ > Cruisecontrolrb-users mailing list > Cruisecontrolrb-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080422/cd5ac558/attachment.html From tim.harding at gmail.com Tue Apr 22 11:08:28 2008 From: tim.harding at gmail.com (Tim Harding) Date: Tue, 22 Apr 2008 16:08:28 +0100 Subject: [Cruisecontrolrb-users] Fail build on code coverage level? In-Reply-To: References: <480CF9F2.6090009@haskinferguson.net> <480CFB67.2020609@gmail.com> <480DEA0D.4000000@haskinferguson.net> Message-ID: But then I don't know anyone that uses Ruby for non-Rails development and the two are nearly synonymous for me, I guess you might not be a Rails developer. On Tue, Apr 22, 2008 at 4:06 PM, Tim Harding wrote: > Just found this: > > "The answer is vl_cruise_control, a Rails plugin that uses rcov to enforce > a coverage target, and causes CC.rb to mark a build as failed if that target > isn't met. So in addition to regularly checking that all the tests pass, we > also check that all (or substantially all) of our code is accounted for in > our tests. " > > Here: > > http://www.viget.com/extend/tools-of-the-trade-vl-cruise-control/ > > That looks like a really nice way of doing what you want... haven't tried > it. > > On Tue, Apr 22, 2008 at 2:37 PM, Denis Haskin > wrote: > > > Thanks to you both -- I'll give that a shot today. > > > > dwh > > > > Chad Woolley wrote: > > > > On Mon, Apr 21, 2008 at 1:39 PM, Bryan Noll wrote: > > > > > > Couldn't you just check in a test that runs `rcov blah ...` somewhere > > and then parses through the results, checking for the percentage value > > you're interested in. > > > > If said percentage value is less than X... assert(false, "You don't have > > enough tests!") > > > > > > Or run this test (or something that just raises an exception if > > coverage is low) only as part of a separate rake task, which runs > > after your rcov task (both called from default cruise task) > > > > -- Chad > > > > > > _______________________________________________ > > Cruisecontrolrb-users mailing list > > Cruisecontrolrb-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080422/873988f6/attachment.html From denis at haskinferguson.net Tue Apr 22 13:29:18 2008 From: denis at haskinferguson.net (Denis Haskin) Date: Tue, 22 Apr 2008 13:29:18 -0400 Subject: [Cruisecontrolrb-users] Fail build on code coverage level? In-Reply-To: References: <480CF9F2.6090009@haskinferguson.net> <480CFB67.2020609@gmail.com> <480DEA0D.4000000@haskinferguson.net> Message-ID: <480E206E.4000504@haskinferguson.net> Thanks for the pointer, I will look at it (weird that it didn't come up in any of my googling). And yes, we're doing Rails. Thanks, dwh Tim Harding wrote: > But then I don't know anyone that uses Ruby for non-Rails development > and the two are nearly synonymous for me, I guess you might not be a > Rails developer. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080422/de1e9cfd/attachment.html 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-users] [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 bill.walton at charter.net Thu Apr 24 21:00:53 2008 From: bill.walton at charter.net (Bill Walton) Date: Thu, 24 Apr 2008 20:00:53 -0500 Subject: [Cruisecontrolrb-users] [ANN] CruiseControl.rb 1.3.0 References: <3945c4270804241628g692f6aaej8d66af975afd996e@mail.gmail.com> Message-ID: <000701c8a66f$cfd2f9b0$6401a8c0@Precision670> Nice! I'm especially in need of the build serialization. The other stuff is terriffic too. Thanks for the great tool! One request for .3.1 ... Maybe (probably ;-) ) I've just had the bad luck not to find the appropriate section of the documentation but, with my config, if the preconditions fail (recent e.g., there're multiple migrations with the same number) the build email still says it passed because there were no errors in the test log (because the tests never ran, so of course there are no errors). If it's there and I'm just missing it, I'd appreciate guidance. If not, it would be great to have a variable to test (of whatever 'physical' form that needs to take) from that reporting method to set the message more appropriately. TIA for considering it. Best regards, Bill From usselmann.m at icg-online.de Fri Apr 25 04:47:23 2008 From: usselmann.m at icg-online.de (Manfred Usselmann) Date: Fri, 25 Apr 2008 10:47:23 +0200 Subject: [Cruisecontrolrb-users] [jruby-user] JRuby and CruiseControl.rb In-Reply-To: <4810B448.9060508@sun.com> References: <20080424180909.f3d19103.usselmann.m@icg-online.de> <4810B448.9060508@sun.com> Message-ID: <20080425104723.860c70ae.usselmann.m@icg-online.de> On Thu, 24 Apr 2008 11:24:40 -0500 Charles Oliver Nutter wrote: > Manfred Usselmann wrote: > [...] > > > Every build is stared with a command like > > > > jruby.bat -e "require 'rubygems' rescue nil; require 'rake'; load > > 'D:/build/cruisecontrol/tasks/cc_build.rake'; ARGV << '--nosearch' > > << '--trace' << 'cc:build'; Rake.application.run; ARGV.clear" > > > > which results in > > > > << was unexpected at this time. > > > > This could be solved if concat would be used instead of the push > > operator: > > > > jruby.bat -e "require 'rubygems' rescue nil; require 'rake'; load > > 'D:/build/cruisecontrol/tasks/cc_build.rake'; ARGV.concat > > ( ['--nosearch', '--trace', 'cc:build' ] ); Rake.application.run; > > ARGV.clear" > > > > Maybe this could be changed within cc.rb? > > This is a problem with our JRuby startup script...in order to pull > off -J arguments we preparse the command line. I would wager that > we're not pulling off the << correctly, or otherwise there's some > parsing issue. Can you show us the full error? '<< was unexpected at this time.' is all I get. Here is a small example: - - - - - - - - - - - - - - - - - - - - - - - - - - C:\>jruby -e "test=['1','2','3'];test << '4' << '5'; puts test" << was unexpected at this time. C:\>jruby -e "test=['1','2','3'];test.concat( ['4','5'] ); puts test" 1 2 3 4 5 C:\> - - - - - - - - - - - - - - - - - - - - - - - - - - > > >> Another issue: I could not find out how to stop a running builder > >> process if I run it with 'cruise start'. If I kill the app with > >> Ctrl-C the builder keeps running in the background and I need to > >> find the belonging java.exe in the task manager... My current > >> workaround is to use 'cruise start -w' and start 'cruise build' > >> separately. I have not yet investigated how to set up > >> cruisecontrol as daemon or service under Windows. > >> > >> And when I request a build via the web browser dashboard the build > >> process starts to loop. The file 'build_requested' does not get > >> removed. > > > > Any suggestion what the reason for this could be or how this could > > be fixed? > > Hmm...not sure I follow. This is for builds spun up in a given JVM, > yes? To be able to kill/shutdown the child process? Yes, the first part is related to builder processes continuing to run as independend processes in the background when I stop the running 'cruise start' with Ctrl-C. Here the code which starts the builder process. - - - - - - - - - - - - - - - - - - - - - - - - - - builder_starter.rb: def self.begin_builder(project_name) cruise_executable = if Platform.interpreter =~ /jruby/ Platform.interpreter + ' ' + path_to_cruise elsif Platform.family == 'mswin32' "ruby #{path_to_cruise}" else path_to_cruise end verbose_option = $VERBOSE_MODE ? " --trace" : "" command = "#{cruise_executable} build #{project_name}#{verbose_option}" Platform.create_child_process(project_name, command) end platform.rb: def create_child_process(project_name, command) if Kernel.respond_to?(:fork) begin pid = fork || exec(command) pid_file = File.join(RAILS_ROOT, 'tmp', 'pids', 'builders', "#{project_name}.pid") FileUtils.mkdir_p(File.dirname(pid_file)) File.open(pid_file, "w") {|f| f.write pid } rescue NotImplementedError # Kernel.fork exists but not implemented in Windows Thread.new { system(command) } end else Thread.new { system(command) } end end module_function :create_child_process - - - - - - - - - - - - - - - - - - - - - - - - - - The problem with the requested build is a separate problem, where the file 'build_requested' does not get removed after the requested build has finished, although it should be by the statement "FileUtils.rm_f(Dir [build_requested_flag_file])" in project.rb. Thanks, Manfred From averkhov at thoughtworks.com Mon Apr 28 12:27:11 2008 From: averkhov at thoughtworks.com (Alexey Verkhovsky) Date: Mon, 28 Apr 2008 11:27:11 -0500 Subject: [Cruisecontrolrb-users] [ANN] CruiseControl.rb 1.3.0 Message-ID: -----cruisecontrolrb-users-bounces at rubyforge.org wrote: ----- > if the preconditions fail > email still says it passed because there were no errors in the test log. CC.rb has no concept of preconditions, and doesn't care about the contents of test log to determine if the build passed or failed. Just the exit code of the build command. If Rake exits with a zero exit code on failure, build passed. So, if migration fails and CC.rb reports test passed, that should be a bug in the build process. Can you please give me more details? 1. Are you running your own Rake tasks, or CC.rb defaults? 2. What does ruby -v say? -- Alex From alexey.verkhovsky at gmail.com Mon Apr 28 17:39:55 2008 From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky) Date: Mon, 28 Apr 2008 15:39:55 -0600 Subject: [Cruisecontrolrb-users] Changes to source control and bug tracking Message-ID: <3945c4270804281439k7f4ebb37o14dcb044bffdd45c@mail.gmail.com> Dear all, I have a couple of things to announce: 1. CruiseControl.rb source code has been moved from Subversion to Git [git://rubyforge.org/cruisecontrolrb.git]. This should make it much easier for people to maintain their own forks of this codebase. So, if you have to hack CC.rb, a good way to do it now is to clone the central git repository; make your changes on a local branch and merge with master whenever it makes sense to do. 2. Bug tracking has been moved to Lighthouse [http://cruisecontrolrb.lighthouseapp.com], with all it's Web 2.0 goodness. Among other things, this means we have a wiki now. -- Alexey Verkhovsky CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] RubyWorks [http://rubyworks.thoughtworks.com] From will.sargent at gmail.com Wed Apr 30 13:16:32 2008 From: will.sargent at gmail.com (Will Sargent) Date: Wed, 30 Apr 2008 10:16:32 -0700 Subject: [Cruisecontrolrb-users] Conflicts with schema.rb? Message-ID: This is interesting, and I'm still not exactly sure what's causing it. When people check in files, occasionally CruiseControl will error out saying that there's a conflict in schema.rb. I can go into cruisecontrol and svn revert the file, but it's cropped up several times, and I'm getting a little tired of it. How does schema.rb work? I've read through The Rails Way and some online references, but I still don't really think I understand how Rails, integration testing and database migration all interact. What's the usual cause of this, and is there some series of steps in CruiseControl or rake that prevents this happening? Will. From javadragon at gmail.com Wed Apr 30 13:35:22 2008 From: javadragon at gmail.com (Lori Olson) Date: Wed, 30 Apr 2008 11:35:22 -0600 Subject: [Cruisecontrolrb-users] Conflicts with schema.rb? In-Reply-To: References: Message-ID: schema.rb is a generated file. It's constructed from your development database structure, and used to create the test database every time you run tests. Although I've seen people argue that you should leave it, in my version control world generated files are never checked in to the repository. You should: 1. delete it from your subversion repository 2. tell svn to ignore it After those two steps, your builds should run more smoothly. Regards, Lori On Wed, Apr 30, 2008 at 11:16 AM, Will Sargent wrote: > This is interesting, and I'm still not exactly sure what's causing it. > > When people check in files, occasionally CruiseControl will error out > saying that there's a conflict in schema.rb. I can go into > cruisecontrol and svn revert the file, but it's cropped up several > times, and I'm getting a little tired of it. > > How does schema.rb work? I've read through The Rails Way and some > online references, but I still don't really think I understand how > Rails, integration testing and database migration all interact. > What's the usual cause of this, and is there some series of steps in > CruiseControl or rake that prevents this happening? > > Will. > _______________________________________________ > Cruisecontrolrb-users mailing list > Cruisecontrolrb-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkimble at inc21.com Wed Apr 30 13:39:32 2008 From: bkimble at inc21.com (Billy Kimble) Date: Wed, 30 Apr 2008 10:39:32 -0700 Subject: [Cruisecontrolrb-users] Conflicts with schema.rb? In-Reply-To: References: Message-ID: <6793BC8D-9E52-4A2E-A80B-06B59DE176A5@inc21.com> Your best bet is to SVN ignore schema.rb. Rails generates it any time you do db:migrate so that when you do db:test:prepare, it will know what schema to make your test environment equal to. If you add a migration and migrate up to that point and commit your schema.rb file, and someone does SVN up but choses not to migrate yet, they are pretty much guaranteed to get conflicts. Billy On Apr 30, 2008, at 10:16 AM, Will Sargent wrote: > This is interesting, and I'm still not exactly sure what's causing it. > > When people check in files, occasionally CruiseControl will error out > saying that there's a conflict in schema.rb. I can go into > cruisecontrol and svn revert the file, but it's cropped up several > times, and I'm getting a little tired of it. > > How does schema.rb work? I've read through The Rails Way and some > online references, but I still don't really think I understand how > Rails, integration testing and database migration all interact. > What's the usual cause of this, and is there some series of steps in > CruiseControl or rake that prevents this happening? > > Will. > _______________________________________________ > Cruisecontrolrb-users mailing list > Cruisecontrolrb-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From bkimble at inc21.com Wed Apr 30 13:41:00 2008 From: bkimble at inc21.com (Billy Kimble) Date: Wed, 30 Apr 2008 10:41:00 -0700 Subject: [Cruisecontrolrb-users] Conflicts with schema.rb? In-Reply-To: References: Message-ID: <7D974DE9-A017-4D47-8A8D-E84EE2A1EEAA@inc21.com> Beat me to it! Drats. Here is a handy article I use any time I need to remember how to properly use SVN ignore. Hope it helps Will. http://wiki.rubyonrails.org/rails/pages/HowtoUseRailsWithSubversion Billy On Apr 30, 2008, at 10:35 AM, Lori Olson wrote: > schema.rb is a generated file. It's constructed from your > development database structure, and used to create the test > database every time you run tests. Although I've seen people argue > that you should leave it, in my version control world generated > files are never checked in to the repository. > > You should: > > 1. delete it from your subversion repository > 2. tell svn to ignore it > > After those two steps, your builds should run more smoothly. > > Regards, Lori > > On Wed, Apr 30, 2008 at 11:16 AM, Will Sargent > wrote: > This is interesting, and I'm still not exactly sure what's causing it. > > When people check in files, occasionally CruiseControl will error out > saying that there's a conflict in schema.rb. I can go into > cruisecontrol and svn revert the file, but it's cropped up several > times, and I'm getting a little tired of it. > > How does schema.rb work? I've read through The Rails Way and some > online references, but I still don't really think I understand how > Rails, integration testing and database migration all interact. > What's the usual cause of this, and is there some series of steps in > CruiseControl or rake that prevents this happening? > > Will. > _______________________________________________ > Cruisecontrolrb-users mailing list > Cruisecontrolrb-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > _______________________________________________ > Cruisecontrolrb-users mailing list > Cruisecontrolrb-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.mcharness at gmail.com Wed Apr 30 15:28:02 2008 From: dan.mcharness at gmail.com (Dan McHarness) Date: Wed, 30 Apr 2008 12:28:02 -0700 Subject: [Cruisecontrolrb-users] Dashboard says there's no project! Message-ID: I'm trying CC.rb for the first time and I'm scratching my head why Dashboard insists there's no project to build. I successfully installed the default cruisecontrolrb-1.3.0, successfully did a "cruise add" of my rails project from svn, and then "cruise start" appears to start ok. However, the Dashboard insists there's no project. The "cruise start" console output: C:\cruisecontrolrb-1.3.0>cruise start cruise data root = 'C:\cruisecontrolrb_projects' => Booting Mongrel (use 'script/server webrick' to force WEBrick) => Rails application starting on http://0.0.0.0:3333 => Call with -d to detach => Ctrl-C to shutdown server C:/InstantRails-1.7-UW/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1-mswin32/bin/mon grel_rails:46: warning: conflicting chdir during another chdir block ** Starting Mongrel listening at 0.0.0.0:3333 ** Starting Rails with production environment... ** Rails loaded. ** Loading any Rails specific GemPlugins ** Signals ready. INT => stop (no restart). ** Mongrel available at 0.0.0.0:3333 ** Use CTRL-C to stop. When I bring up http://localhost:3333/ I get the following web page output: Welcome to CruiseControl.rb! There are no projects in the projects directory [C:\cruisecontrolrb_projects/projects] yet. And the consequent console output is a repeat of the following output every ~5 seconds: Processing ProjectsController#index (for 127.0.0.1 at 2008-04-30 12:14:58) [GET] Parameters: {"action"=>"index", "controller"=>"projects"} Rendering layoutfalsecontent_typetext/htmlactionindex within layouts/default Rendering projects/index Completed in 0.03100 (32 reqs/sec) | Rendering: 0.03100 (100%) | 200 OK [http:// localhost/] ost/] I haven't made any configuration changes other than to repoint CRUISE_DATA_ROOT. There were no errors or warnings reported on the console during the "cruise add" checkout from svn, however, do you think the warning reported above in the console output from the "cruise start" command the source of the problem? thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From averkhov at thoughtworks.com Wed Apr 30 15:27:19 2008 From: averkhov at thoughtworks.com (Alexey Verkhovsky) Date: Wed, 30 Apr 2008 14:27:19 -0500 Subject: [Cruisecontrolrb-users] Conflicts with schema.rb? Message-ID: > When people check in files, occasionally CruiseControl will error out > saying that there's a conflict in schema.rb. schema.rb is auto-generated on every build. If you have it checked in, by the time the build is over, you may have a locally changed schema.rb and when CC.rb tries to run an update, it may end up with a conflict. The "Rails Way" is to have schema.rb in svn:ignore, and build your database from migrations. -- Alex From alexey.verkhovsky at gmail.com Wed Apr 30 15:31:41 2008 From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky) Date: Wed, 30 Apr 2008 13:31:41 -0600 Subject: [Cruisecontrolrb-users] Dashboard says there's no project! In-Reply-To: References: Message-ID: <3945c4270804301231j247a5b7cw9243986cd566d506@mail.gmail.com> On Wed, Apr 30, 2008 at 1:28 PM, Dan McHarness wrote: > I haven't made any configuration changes other than to repoint > CRUISE_DATA_ROOT. Does it work if you do not define a custom CRUISE_DATA_ROOT? -- Alexey Verkhovsky CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] RubyWorks [http://rubyworks.thoughtworks.com] From jeremystellsmith at gmail.com Wed Apr 30 15:31:12 2008 From: jeremystellsmith at gmail.com (Jeremy Stell-Smith) Date: Wed, 30 Apr 2008 12:31:12 -0700 Subject: [Cruisecontrolrb-users] Dashboard says there's no project! In-Reply-To: References: Message-ID: nope, that warning is unfortunately expected. what files / directories do you have in c:/cruisecontrolrb_projects/? On Wed, Apr 30, 2008 at 12:28 PM, Dan McHarness wrote: > I'm trying CC.rb for the first time and I'm scratching my head why > Dashboard insists there's no project to build. > > I successfully installed the default cruisecontrolrb-1.3.0, successfully > did a "cruise add" of my rails project from svn, and then "cruise start" > appears to start ok. However, the Dashboard insists there's no project. > > The "cruise start" console output: > > C:\cruisecontrolrb-1.3.0>cruise start > cruise data root = 'C:\cruisecontrolrb_projects' > => Booting Mongrel (use 'script/server webrick' to force WEBrick) > => Rails application starting on http://0.0.0.0:3333 > => Call with -d to detach > => Ctrl-C to shutdown server > > C:/InstantRails-1.7-UW/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1-mswin32/bin/mon > grel_rails:46: warning: conflicting chdir during another chdir block > ** Starting Mongrel listening at 0.0.0.0:3333 > ** Starting Rails with production environment... > ** Rails loaded. > ** Loading any Rails specific GemPlugins > ** Signals ready. INT => stop (no restart). > ** Mongrel available at 0.0.0.0:3333 > ** Use CTRL-C to stop. > > When I bring up http://localhost:3333/ I get the following web page > output: > > Welcome to CruiseControl.rb! > There are no projects in the projects directory > [C:\cruisecontrolrb_projects/projects] yet. > > And the consequent console output is a repeat of the following output > every ~5 seconds: > > Processing ProjectsController#index (for 127.0.0.1 at 2008-04-30 12:14:58) > [GET] > > Parameters: {"action"=>"index", "controller"=>"projects"} > Rendering layoutfalsecontent_typetext/htmlactionindex within > layouts/default > Rendering projects/index > Completed in 0.03100 (32 reqs/sec) | Rendering: 0.03100 (100%) | 200 OK > [http:// > localhost/] > ost/] > > I haven't made any configuration changes other than to repoint > CRUISE_DATA_ROOT. > > There were no errors or warnings reported on the console during the > "cruise add" checkout from svn, however, do you think the warning reported > above in the console output from the "cruise start" command the source of > the problem? > > thanks > > _______________________________________________ > Cruisecontrolrb-users mailing list > Cruisecontrolrb-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.mcharness at gmail.com Wed Apr 30 15:40:29 2008 From: dan.mcharness at gmail.com (Dan McHarness) Date: Wed, 30 Apr 2008 12:40:29 -0700 Subject: [Cruisecontrolrb-users] Dashboard says there's no project! In-Reply-To: <3945c4270804301231j247a5b7cw9243986cd566d506@mail.gmail.com> References: <3945c4270804301231j247a5b7cw9243986cd566d506@mail.gmail.com> Message-ID: I turned off CRUISE_DATA_ROOT, repeat the steps and get the exact same outcome. weird. It's like its trying to run something in cc.rb ( Parameters: {"format"=>"js", "action"=>"index", "controller"=>"projects"} ) instead of my project. On Wed, Apr 30, 2008 at 12:31 PM, Alexey Verkhovsky < alexey.verkhovsky at gmail.com> wrote: > On Wed, Apr 30, 2008 at 1:28 PM, Dan McHarness > wrote: > > I haven't made any configuration changes other than to repoint > > CRUISE_DATA_ROOT. > > Does it work if you do not define a custom CRUISE_DATA_ROOT? > > -- > Alexey Verkhovsky > CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] > RubyWorks [http://rubyworks.thoughtworks.com] > _______________________________________________ > Cruisecontrolrb-users mailing list > Cruisecontrolrb-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.mcharness at gmail.com Wed Apr 30 15:41:39 2008 From: dan.mcharness at gmail.com (Dan McHarness) Date: Wed, 30 Apr 2008 12:41:39 -0700 Subject: [Cruisecontrolrb-users] Dashboard says there's no project! In-Reply-To: References: Message-ID: I turned off CRUISE_DATA_ROOT, repeated the steps, and get the exact same output and results. Weird. On Wed, Apr 30, 2008 at 12:31 PM, Jeremy Stell-Smith < jeremystellsmith at gmail.com> wrote: > nope, that warning is unfortunately expected. > > what files / directories do you have in c:/cruisecontrolrb_projects/? > > On Wed, Apr 30, 2008 at 12:28 PM, Dan McHarness > wrote: > > > I'm trying CC.rb for the first time and I'm scratching my head why > > Dashboard insists there's no project to build. > > > > I successfully installed the default cruisecontrolrb-1.3.0, successfully > > did a "cruise add" of my rails project from svn, and then "cruise start" > > appears to start ok. However, the Dashboard insists there's no project. > > > > The "cruise start" console output: > > > > C:\cruisecontrolrb-1.3.0>cruise start > > cruise data root = 'C:\cruisecontrolrb_projects' > > => Booting Mongrel (use 'script/server webrick' to force WEBrick) > > => Rails application starting on http://0.0.0.0:3333 > > => Call with -d to detach > > => Ctrl-C to shutdown server > > > > C:/InstantRails-1.7-UW/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1-mswin32/bin/mon > > grel_rails:46: warning: conflicting chdir during another chdir block > > ** Starting Mongrel listening at 0.0.0.0:3333 > > ** Starting Rails with production environment... > > ** Rails loaded. > > ** Loading any Rails specific GemPlugins > > ** Signals ready. INT => stop (no restart). > > ** Mongrel available at 0.0.0.0:3333 > > ** Use CTRL-C to stop. > > > > When I bring up http://localhost:3333/ I get the following web page > > output: > > > > Welcome to CruiseControl.rb! > > There are no projects in the projects directory > > [C:\cruisecontrolrb_projects/projects] yet. > > > > And the consequent console output is a repeat of the following output > > every ~5 seconds: > > > > Processing ProjectsController#index (for 127.0.0.1 at 2008-04-30 > > 12:14:58) [GET] > > > > Parameters: {"action"=>"index", "controller"=>"projects"} > > Rendering layoutfalsecontent_typetext/htmlactionindex within > > layouts/default > > Rendering projects/index > > Completed in 0.03100 (32 reqs/sec) | Rendering: 0.03100 (100%) | 200 OK > > [http:// > > localhost/] > > ost/] > > > > I haven't made any configuration changes other than to repoint > > CRUISE_DATA_ROOT. > > > > There were no errors or warnings reported on the console during the > > "cruise add" checkout from svn, however, do you think the warning reported > > above in the console output from the "cruise start" command the source of > > the problem? > > > > thanks > > > > _______________________________________________ > > Cruisecontrolrb-users mailing list > > Cruisecontrolrb-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > > > > > > _______________________________________________ > Cruisecontrolrb-users mailing list > Cruisecontrolrb-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From averkhov at thoughtworks.com Wed Apr 30 15:42:54 2008 From: averkhov at thoughtworks.com (Alexey Verkhovsky) Date: Wed, 30 Apr 2008 14:42:54 -0500 Subject: [Cruisecontrolrb-users] [ANN] CruiseControl.rb 1.3.0 Message-ID: >to add a PASSED/FAILED message to the >email subject line. It reports correctly if a test fails. OK, so the build process does exit with non-zero code, and CC.rb does know that the build has failed. It also should put "passed" or "failed" into the subject of the email. This happens at lib/builder_plugins/email_notifier.rb, lines 40 and 46. >How can I capture the errors that occur in >task :cruise =>['db:migrate', 'db:test:purge', >'db:test:clone_structure'] >so as to put the correct message on the email subject line? Assuming that they do write something out into the stdout/stderr, you should still see these failures in the build log section of the dashboard page for that build. To add them to the email, you'd probably have to rescue the errors (in the Rake build) and write them out to stderr in such a way that can then be parsed. Then parse them out of build.output (which is just the stderr+stdout of the build process). The build object is available to all event handlers in the EmailNotifier (that would be build_fixed() and build_finished() methods). -- Alex From jeremystellsmith at gmail.com Wed Apr 30 15:58:00 2008 From: jeremystellsmith at gmail.com (Jeremy Stell-Smith) Date: Wed, 30 Apr 2008 12:58:00 -0700 Subject: [Cruisecontrolrb-users] Dashboard says there's no project! In-Reply-To: References: Message-ID: you're going to need to stop and restart the cruise control server for that change to take effect On Wed, Apr 30, 2008 at 12:41 PM, Dan McHarness wrote: > I turned off CRUISE_DATA_ROOT, repeated the steps, and get the exact same > output and results. Weird. > > > On Wed, Apr 30, 2008 at 12:31 PM, Jeremy Stell-Smith < > jeremystellsmith at gmail.com> wrote: > > > nope, that warning is unfortunately expected. > > > > what files / directories do you have in c:/cruisecontrolrb_projects/? > > > > On Wed, Apr 30, 2008 at 12:28 PM, Dan McHarness > > wrote: > > > > > I'm trying CC.rb for the first time and I'm scratching my head why > > > Dashboard insists there's no project to build. > > > > > > I successfully installed the default cruisecontrolrb-1.3.0, > > > successfully did a "cruise add" of my rails project from svn, and then > > > "cruise start" appears to start ok. However, the Dashboard insists there's > > > no project. > > > > > > The "cruise start" console output: > > > > > > C:\cruisecontrolrb-1.3.0>cruise start > > > cruise data root = 'C:\cruisecontrolrb_projects' > > > => Booting Mongrel (use 'script/server webrick' to force WEBrick) > > > => Rails application starting on http://0.0.0.0:3333 > > > => Call with -d to detach > > > => Ctrl-C to shutdown server > > > > > > C:/InstantRails-1.7-UW/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1-mswin32/bin/mon > > > grel_rails:46: warning: conflicting chdir during another chdir block > > > ** Starting Mongrel listening at 0.0.0.0:3333 > > > ** Starting Rails with production environment... > > > ** Rails loaded. > > > ** Loading any Rails specific GemPlugins > > > ** Signals ready. INT => stop (no restart). > > > ** Mongrel available at 0.0.0.0:3333 > > > ** Use CTRL-C to stop. > > > > > > When I bring up http://localhost:3333/ I get the following web page > > > output: > > > > > > Welcome to CruiseControl.rb! > > > There are no projects in the projects directory > > > [C:\cruisecontrolrb_projects/projects] yet. > > > > > > And the consequent console output is a repeat of the following output > > > every ~5 seconds: > > > > > > Processing ProjectsController#index (for 127.0.0.1 at 2008-04-30 > > > 12:14:58) [GET] > > > > > > Parameters: {"action"=>"index", "controller"=>"projects"} > > > Rendering layoutfalsecontent_typetext/htmlactionindex within > > > layouts/default > > > Rendering projects/index > > > Completed in 0.03100 (32 reqs/sec) | Rendering: 0.03100 (100%) | 200 > > > OK [http:// > > > localhost/] > > > ost/] > > > > > > I haven't made any configuration changes other than to repoint > > > CRUISE_DATA_ROOT. > > > > > > There were no errors or warnings reported on the console during the > > > "cruise add" checkout from svn, however, do you think the warning reported > > > above in the console output from the "cruise start" command the source of > > > the problem? > > > > > > thanks > > > > > > _______________________________________________ > > > Cruisecontrolrb-users mailing list > > > Cruisecontrolrb-users at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > > > > > > > > > > _______________________________________________ > > Cruisecontrolrb-users mailing list > > Cruisecontrolrb-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > > > > > > _______________________________________________ > Cruisecontrolrb-users mailing list > Cruisecontrolrb-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.mcharness at gmail.com Wed Apr 30 16:17:50 2008 From: dan.mcharness at gmail.com (Dan McHarness) Date: Wed, 30 Apr 2008 13:17:50 -0700 Subject: [Cruisecontrolrb-users] Dashboard says there's no project! In-Reply-To: <3945c4270804301231j247a5b7cw9243986cd566d506@mail.gmail.com> References: <3945c4270804301231j247a5b7cw9243986cd566d506@mail.gmail.com> Message-ID: As a follow up, I've also tested against stock installs of InstantRails v1.7 and v2.0 with the same reported outcome. I've insured that the ruby in v1.7 (v1.8.6) has been patched to level 111. IR v2.0 is already at patch level 111. So, I don't think that's the source of the problem... On Wed, Apr 30, 2008 at 12:31 PM, Alexey Verkhovsky < alexey.verkhovsky at gmail.com> wrote: > On Wed, Apr 30, 2008 at 1:28 PM, Dan McHarness > wrote: > > I haven't made any configuration changes other than to repoint > > CRUISE_DATA_ROOT. > > Does it work if you do not define a custom CRUISE_DATA_ROOT? > > -- > Alexey Verkhovsky > CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] > RubyWorks [http://rubyworks.thoughtworks.com] > _______________________________________________ > Cruisecontrolrb-users mailing list > Cruisecontrolrb-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at benburkert.com Wed Apr 30 17:57:42 2008 From: ben at benburkert.com (Ben Burkert) Date: Wed, 30 Apr 2008 16:57:42 -0500 Subject: [Cruisecontrolrb-users] Changes to source control and bug tracking In-Reply-To: <3945c4270804281439k7f4ebb37o14dcb044bffdd45c@mail.gmail.com> References: <3945c4270804281439k7f4ebb37o14dcb044bffdd45c@mail.gmail.com> Message-ID: <13de14180804301457v1c46bcbwb2adb3e2ed14f8c@mail.gmail.com> Does this mean ccrb will have git support in the official branch? -Ben On 4/28/08, Alexey Verkhovsky wrote: > > Dear all, > > I have a couple of things to announce: > > 1. CruiseControl.rb source code has been moved from Subversion to Git > [git://rubyforge.org/cruisecontrolrb.git]. This should make it much > easier for people to maintain their own forks of this codebase. So, if > you have to hack CC.rb, a good way to do it now is to clone the > central git repository; make your changes on a local branch and merge > with master whenever it makes sense to do. > > 2. Bug tracking has been moved to Lighthouse > [http://cruisecontrolrb.lighthouseapp.com], with all it's Web 2.0 > goodness. Among other things, this means we have a wiki now. > > > -- > Alexey Verkhovsky > CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] > RubyWorks [http://rubyworks.thoughtworks.com] > _______________________________________________ > Cruisecontrolrb-users mailing list > Cruisecontrolrb-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremystellsmith at gmail.com Wed Apr 30 18:20:43 2008 From: jeremystellsmith at gmail.com (Jeremy Stell-Smith) Date: Wed, 30 Apr 2008 15:20:43 -0700 Subject: [Cruisecontrolrb-users] Changes to source control and bug tracking In-Reply-To: <13de14180804301457v1c46bcbwb2adb3e2ed14f8c@mail.gmail.com> References: <3945c4270804281439k7f4ebb37o14dcb044bffdd45c@mail.gmail.com> <13de14180804301457v1c46bcbwb2adb3e2ed14f8c@mail.gmail.com> Message-ID: that's what alexey is working on right now. it's not there yet, though. On Wed, Apr 30, 2008 at 2:57 PM, Ben Burkert wrote: > Does this mean ccrb will have git support in the official branch? > > -Ben > > > On 4/28/08, Alexey Verkhovsky wrote: > > > > Dear all, > > > > I have a couple of things to announce: > > > > 1. CruiseControl.rb source code has been moved from Subversion to Git > > [git://rubyforge.org/cruisecontrolrb.git]. This should make it much > > easier for people to maintain their own forks of this codebase. So, if > > you have to hack CC.rb, a good way to do it now is to clone the > > central git repository; make your changes on a local branch and merge > > with master whenever it makes sense to do. > > > > 2. Bug tracking has been moved to Lighthouse > > [http://cruisecontrolrb.lighthouseapp.com], with all it's Web 2.0 > > goodness. Among other things, this means we have a wiki now. > > > > > > -- > > Alexey Verkhovsky > > CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] > > RubyWorks [http://rubyworks.thoughtworks.com] > > _______________________________________________ > > Cruisecontrolrb-users mailing list > > Cruisecontrolrb-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > > > > > _______________________________________________ > Cruisecontrolrb-users mailing list > Cruisecontrolrb-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.verkhovsky at gmail.com Wed Apr 30 18:52:36 2008 From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky) Date: Wed, 30 Apr 2008 16:52:36 -0600 Subject: [Cruisecontrolrb-users] Changes to source control and bug tracking In-Reply-To: <13de14180804301457v1c46bcbwb2adb3e2ed14f8c@mail.gmail.com> References: <3945c4270804281439k7f4ebb37o14dcb044bffdd45c@mail.gmail.com> <13de14180804301457v1c46bcbwb2adb3e2ed14f8c@mail.gmail.com> Message-ID: <3945c4270804301552sb5ab0c6g70c84dcc5485c3aa@mail.gmail.com> On Wed, Apr 30, 2008 at 3:57 PM, Ben Burkert wrote: > Does this mean ccrb will have git support in the official branch? Oh, yes. We are a CI tool project without our own CI loop at the moment, and we can'[t let it stay that way, can we? By the way, it's really sad, but I couldn't simply merge in your fork - can't have binary dependencies in a shrink-wrapped product. -- Alexey Verkhovsky CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] RubyWorks [http://rubyworks.thoughtworks.com] From ben at benburkert.com Wed Apr 30 19:08:14 2008 From: ben at benburkert.com (Ben Burkert) Date: Wed, 30 Apr 2008 18:08:14 -0500 Subject: [Cruisecontrolrb-users] Changes to source control and bug tracking In-Reply-To: <3945c4270804301552sb5ab0c6g70c84dcc5485c3aa@mail.gmail.com> References: <3945c4270804281439k7f4ebb37o14dcb044bffdd45c@mail.gmail.com> <13de14180804301457v1c46bcbwb2adb3e2ed14f8c@mail.gmail.com> <3945c4270804301552sb5ab0c6g70c84dcc5485c3aa@mail.gmail.com> Message-ID: <13de14180804301608r4e53ad67sd1c0fd255585cec5@mail.gmail.com> I assume you're talking about grit? I don't think it has any C extensions, so you should be able to vendor it without a problem. -Ben On 4/30/08, Alexey Verkhovsky wrote: > > On Wed, Apr 30, 2008 at 3:57 PM, Ben Burkert wrote: > > > Does this mean ccrb will have git support in the official branch? > > > Oh, yes. We are a CI tool project without our own CI loop at the > moment, and we can'[t let it stay that way, can we? > By the way, it's really sad, but I couldn't simply merge in your fork > - can't have binary dependencies in a shrink-wrapped product. > > > -- > > Alexey Verkhovsky > CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] > RubyWorks [http://rubyworks.thoughtworks.com] > _______________________________________________ > Cruisecontrolrb-users mailing list > Cruisecontrolrb-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: