Cruisecontrolrb users - May 2008 - Git support - kinda works, have design questions

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]

Alex, have you considered using a shortened version of the revision  
hash for display? With git, you can do ''git rev-parse --short
HEAD'' to
get a more readable but unique enough revision hash to id the build  
with. I''m not sure if mercurial or other distributed vc systems have  
such an option, but it would work for git at least. Just a thought.

- Jason

On 6-May-08, at 3:53 PM, Alexey Verkhovsky wrote:
> 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
> Cruisecontrolrb-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users

On Tue, May 6, 2008 at 5:28 PM, Jason Sallis <jsallis at gmail.com>
wrote:
> Alex, have you considered using a shortened version of the revision hash
for
> display? With git, you can do ''git rev-parse --short
HEAD'' to get a more
> readable but unique enough revision hash to id the build with. I''m
not sure
> if mercurial or other distributed vc systems have such an option, but it
> would work for git at least. Just a thought.
>
>  - Jason
This seems like a great solution, Jason.  I''d definitely avoid a
manually generated build ID - having the build ID tied directly to SCM
is one of the nice things about cc.rb.

On Tue, May 6, 2008 at 5:53 PM, Alexey Verkhovsky
<alexey.verkhovsky at gmail.com> wrote:
>  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?
Personally, I''d strongly prefer generated build numbers, because they
actually *mean* something to humans, and mtime isn''t very obvious and
is potentially fragile.  Then again, I also strongly prefer bazaar (or
mercurial) to git, and they both provide (branch-specific) revision
numbers in addition to the (globally unique) revision id, so perhaps
my bias is not the same as a git lover''s bias.  But surely by now
someone has written a git plugin/script that will tell you a branch''s
current revision number?  It seems like a trivial thing to do.

Another option: you could use a concise date-based build number, e.g.
the output from:

 date "+%y-%j"
 08-128

Then the git fans won''t be offended that you''ve used an
"obviously
inferior" revision number instead of a precious SHA1 hash derivative.
;-P

-- 
Nick

On Wed, May 7, 2008 at 6:07 AM, nicholas a. evans <nick at ekenosen.net>
wrote:
>  >  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.
>  Personally, I''d strongly prefer generated build numbers
In the latest checkin, we are abbreviating global changeset ids (long
random hex strings) for both Git and Mercurial to the first five
characters. It turns out that both Git and Mercurial allow you to
specify changesets in this way, so it is a meaningful label, problem
solved.

5 characters sounds like a short string. We thought about what happens
if two changesets have the same first five characters. First of all,
16^5 is just above a million, so chances of that actually happening
are not that big. And then, consequences are not that serious - it
will just create a new build with the .1 suffix, like it was a
rebuild.

We are also sorting builds by mtime of the build directory. Whether
this is a performance concern remains to be seen by testing on a
project with large number of builds.

Bottom line: Mercurial and Git support available from the master
repository (previously known as trunk) passes some tests and looks
usable by now. If you need it desperately enough to deal with
unreleased software, please try it out and see what happens.

-- 
Alexey Verkhovsky
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
RubyWorks [http://rubyworks.thoughtworks.com]