[Buildbot-devel] monitoring and tagging multiple git repositories

Dustin J. Mitchell dustin at v.igoro.us
Sun Jun 12 18:28:24 UTC 2011

On Sun, Jun 12, 2011 at 7:31 AM, Dickon Reed <dickon at cantab.net> wrote:
> A common concern (I know people on my project car) is that people get
> nervous when there is version information canonically in an automation
> system such as Buildbot, because they wish to maintain visibility through
> the version control systems of what exactly went into each automated build,
> and the ability to build manually. I think most version control systems
> support symbolic tags and in some cases people probably want the aggregate
> sourcestamp stored.

Sure, so add this to the pile of desires.  Certainly folks building
projects across e.g., Git and Mercurial can't use symbolic tags,
though, so some amount of revision state will need to be stored in

> If we maintain the correspondence between change sources and repositories
> (unlike in my experimental branch), then perhaps when the scheduler kicks
> off a build with an aggregate source stamp there should be a callback from
> the scheduler to each change source to give the change source an opportunity
> to associate a symbolic tag for the build version with the revision of its
> repository that is being built.  That would actually be better for my
> project than my first idea to put everything into a git change source since
> we do have some upstream sources using Mercurial.

This sounds good.  Actually, it gets to another idea I've had, which
is to construct "Source Managers" which do the work of a change
source, but can also be consulted e.g., to find all of the commits
between two revisions (for a blamelist) or to determine which change
came first (to help sorting builds).  This sort of callback would be a
natural addition to such a manager.

> Support in the web interface for requesting builds according to a symbolic
> tag that is present in each repository may also be useful in some cases. It
> would also be useful to see some indication of the aggregate source version
> and the symbolic tag associated with it in the waterfall.

Indeed, but you're thinking very specifically about your needs and
assuming the use of tags - can you generalize?


More information about the devel mailing list