Allow for "git describe" in addition to got_revision

[jaredgrubb]

It would be nice if there was a flag to retrieve the "git describe" value for the checked out revision, just like buildbot does for got_revision.

[dustin]

I think that this would be best handled with a separate shellcommand. With multirepo support, it's not clear where such a value would go (in fact, got_revision has caused some consternation, too).

[jaredgrubb]

So I suppose a "got_description" added into the sourcestamp would be not workable?

One alternative is that got_revision could be filled with the description instead of the revision based on some boolean option (along with something to get the right revision out for a subsequent rebuild).

Locally I've been just adding it as a property named "got_descirption{%s}"%project.

[dustin]

I don't want to add additional fields to sourcestamps. I think a property is the right approach, and you're close - probably including the codebase in the property name is the right approach.

[tom.prince]

Or having the property be a dictionary, rather than a string, would also work. Although, at this point we don't have any tools for working with such things easily.

On the other hand, it would be nice if buildbot where more aware of the history of repositories, and this would be reasonable information to know. (Except of course that there are many possible option you might want to pass to 'git describe').

Do other version control systems have something similliar?

[jaredgrubb]

Yeh, I didnt consider it, but "git describe" does have args you might want to alter (eg, --abbrev and --tags come to mind). So, maybe this really is a separate Step class and not built into the Git class.

It looks like you can make hg do something similar ( http://mercurial.selenic.com/wiki/GitConcepts).

[jaredgrubb]

I have a patch ready for this. What I've implemented is an new param to Git which will do a 'git describe' after the 'git rev-parse' step.

• Git(..., getDescription=True) => "git describe HEAD"
• Git(..., getDescription={'match': 'foo-*'}) => "git describe --match foo-* HEAD"
• Git(..., getDescription={'tags': True, 'exact-match': True}) => "git describe --tags --exact-match HEAD"
• Git(..., getDescription={'match': 'foo-*', 'abbrev': 0}) => "git describe --match foo-* --abbrev=0 HEAD"

The description is then added to the property 'got_description', which is a dict keyed by codebase. I figure since this is a 0.8.7 feature, if people want to use it, then keying by codebase (or using the default codebase=) is a reasonable expectation.

If you dont mind this approach, I'll do a pull request.

[dustin]

I like the flexibility of it, for sure. We don't currently have a great way to get properties out of dictionaries, though, and I'm loathe to create a desire for that.

Way back when we first started talking about dictionaries in properties, we were thinking of keying them on repostitory (we hadn't invented "codebase" yet). I wonder if this would be *more* usable if the properties were just named with the codebase, e.g., "%s-commit-description", maybe with a fallback to just "commit-description" for the empty codebase?

I'm not suggesting that change just yet -- I'd like to hear what others think first.

[jaredgrubb]

I saw that lists are supported ('owners' is set to [u'jgrubb'] on my 0.8.6 bot), so I assumed dict's were ok too.

Before I did the dict approach, I was doing "got_description{%s}" in my own bot ... if someone wanted something different from the default prop name, could provide a 'set-property' key or something in the getDescription dict; hey, it could even be a callable! ... Maybe that's too many custom knobs before anyone's asked for it, but thought I'd throw it out there.

[dustin]

I suspect that the common use-case is to substitute the description into a filename somewhere, and for that folks will want to use Interpolate. Let's go with the property-per-codebase approach described in comment 7, or the variant in comment 8, and see how that flies. If there are good reasons to use a dictionary, too, we can add that in without any problems.

[dustin]

Note, too, that some big changes to Interpolate are about to land, so you may want to work on top of tomprince's branch until it gets merged:

 https://github.com/buildbot/buildbot/pull/290

[Jared Grubb]

Fixes #2180: Allow for "git describe" in addition to got_revision

Changeset: 31736e2ae006471bfd392807d7b4ad3385345472

[Dustin J. Mitchell]

Merge branch 'git-describe' of  git://github.com/jaredgrubb/buildbot

• 'git-describe' of  git://github.com/jaredgrubb/buildbot: git-describe: update release notes; also fix a misplaced note for the 'descriptionSuffix' change git-describe: update docs; adjust behavior of 'dict()' Fixes #2180: Allow for "git describe" in addition to got_revision Changeset: ec6e2e8cabd2c8eec04b11ef6a5e63cc6cd4cefd