As of now, I can create a project from Git repository, run a builder on it, and even run the dashboard. Build pages look ugly because build.label in git is very long, a bunch of unit tests is failing, and I had to disable some functionality, namely displaying source control errors in the dashboard.
SourceControl::AbstractAdapter#execute_with_error_log (formerly known as Subversion::execute_with_error_log) had a bold assumption that any command writing anything in stderr has failed. This is not true for Git. Actually (and this really sucks), I even found a case where Git command returns a non-zero exit code upon successful completion. Namely, "git remote update" - I had to replace that with lower level "git fetch origin" that seems to do the right thing. None of that is documented behavior, as far as I can tell. Anyhow, it works for some value of "works" now. ThoughtWorks IS needs to punch a hole in the firewall so that ccrb.tw.com can talk to RubyForge Git server. Once that is done, I am deploying the current tip. Meantime, there is one pretty important design decision to be made. Commit id in distributed source control systems tends to be a very long random hex string. So, our convention of using revision number as build labels doesn't work - neither for displaying, nor for ordering builds. If we still use those hashes for build labels, we'll need to order builds by mtime of a build directory and display abbreviated build labels instead of full ones. Or we need to generate our own build numbers. Either way sucks, in its own special way. Does anyone have a strong preference or a better idea? -- Alexey Verkhovsky CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] RubyWorks [http://rubyworks.thoughtworks.com] _______________________________________________ Cruisecontrolrb-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
