Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#2180 closed enhancement (fixed)

Allow for "git describe" in addition to got_revision

Reported by: jaredgrubb Owned by: jaredgrubb
Priority: minor Milestone: 0.8.7
Version: 0.8.5 Keywords: git


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.

Change History (13)

comment:1 Changed 9 years ago by dustin

  • Resolution set to wontfix
  • Status changed from new to closed

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).

comment:2 Changed 9 years ago by 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.

comment:3 Changed 9 years ago by 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.

comment:4 Changed 9 years ago by 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?

comment:5 Changed 9 years ago by 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 (

comment:6 Changed 9 years ago by 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.

comment:7 Changed 9 years ago by dustin

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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.

comment:8 Changed 9 years ago by 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.

comment:9 Changed 9 years ago by jaredgrubb

  • Owner set to jaredgrubb
  • Status changed from reopened to assigned

comment:10 Changed 9 years ago by 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.

comment:11 Changed 8 years ago by dustin

  • Keywords buildslave removed
  • Milestone changed from undecided to 0.8.7

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:

comment:12 Changed 8 years ago by Jared Grubb

  • Resolution set to fixed
  • Status changed from assigned to closed

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

Changeset: 31736e2ae006471bfd392807d7b4ad3385345472

comment:13 Changed 8 years ago by Dustin J. Mitchell

Merge branch 'git-describe' of git://

Note: See TracTickets for help on using tickets.