Cruisecontrolrb Cruise Control.rb → 1.1

Here is a bunch of complaints on the subject, received from Mr. Sarnacke: Because the server I was putting this app on is behind a firewall, I wanted to run cruisecontrolrb and proxy it through Apache so I can hit it through port 80 without having to mess with the FW configuration. I didn't want to run "cruise start", and just leave it in a screen session, or running in a terminal, nor doing "cruise start &" which doesn't work, that has something to do with mongrel IIRC. I wanted to run it as a true daemon, so that it would come up at reboot, and I could start/stop it in a "normal" manner. I started by creating a cruisecontrolrb user, unpacking the distribution, chown'ing it all to root, then chowning just [cruise]/projects (had to create that) and the [cruise]/log directories to the cruisecontrolrb user, to give it the proper access to create logs and projects. Even though we are on a private network, I still like to deploy things "properly", only giving the access required to run the application, and not allowing anything to be written to that shouldn't be written to. Since I wanted to use it as a "normal" daemon, I tried running 'cruise start' with the -d option, which seemed to work, but it doesn't understand "cruise stop", so that was not a good solution. I then tried to set it up using mongrel cluster, with it running as the cruisecontrolrb user, on a specific port, and with just one mongrel instance running. Doing it this way allowed the web server to run, but when I tried to start the build processes through the interface I would get: [error] undefined method `number' for nil:NilClass [error] /var/www/rails_apps/cruisecontrolrb-1.0.0/config/../script/../config/../app/models/pr oject.rb:216:in `build' [error] /var/www/rails_apps/cruisecontrolrb-1.0.0/config/../script/../config/../app/models/pr oject.rb:203:in `build_if_requested' [error] /var/www/rails_apps/cruisecontrolrb-1.0.0/config/../script/../config/../app/models/po lling_scheduler.rb:26:in `check_build_request_until_next_polling' [error] /var/www/rails_apps/cruisecontrolrb-1.0.0/config/../script/../config/../app/models/po lling_scheduler.rb:13:in `run' [error] /var/www/rails_apps/cruisecontrolrb-1.0.0/config/../script/builder:78 [error] /var/www/rails_apps/cruisecontrolrb-1.0.0/config/../script/builder:77 [error] /var/www/rails_apps/cruisecontrolrb-1.0.0/config/../cruise:13:in `builder' [error] /var/www/rails_apps/cruisecontrolrb-1.0.0/config/../cruise:65 I didn't see a good way to run the build proceses separately, and I really didn't want to. I wanted everything to run out of the main mongrel process that was running the web interface. I didn't want to have to remember to start the build processes, or have to manage them separately from the main mongrel process serving the web content. I found through some testing that if I su'd to the cruisecontrolrb user, and then ran mongrel cluster, that it would work fine. You could start the build processes through the web interface, and everything would work. Since that defeated the purpose of using mongrel cluster, since I couldn't just link the config to /etc/mongrel_cluster and control it with the rest of the mongrel clusters on the box, I ended up writing a custom init script that simply su'd to the cruisecontrolrb user and ran the process using mongrel_rails, giving it specfic address, port and environment information. The other problem with that is that the builder pids are not written in the log directory, making them hard to find programmatically, and the pid file has nothing in it, so even if they were in the log directory, they would be useless for controlling the builder processes. For now, I do some grep/awk magic to find the builder processes and kill them when I want to bounce cruisecontrol. The lasting problem with that is if the box (or the mongrel_rails process) bounces, then you have to start the build processes again manually, which I don't like, but since I've already spent more time on this than I should have, I'll live with it for now. Another problem was the email. Our email server silently accepts emails that it thinks are relays, and then just drops them. I ended up having to edit app/models/build_mailer.rb to set the @from address properly so that our email server would deliver the email. This should be in the in the per-project cruise_config.rb. There were some other issues with getting the rake tasks to actually finish correctly, but I think that this had more to do with our specific projects than with cruisecontrolrb. The trick seemed to be to make the custom - task (project.rake_task) "test". I would have thought it would have done that by default, but there seemed to be a problem with it. I don't know exactly what that was, and again, I can't spend any more time on it to find out.