[Buildbot-devel] Add repository path to the Source object

[Marcus Lindblom]

On 2010-01-07 13:36, Benoît Allard wrote:
> Hi There,
>
> Currently, the "Change" object (from buildbot.changes.changes import
> Change) has information about a changeset: at least who did it, files
> involved, and comments about it. This can be extended with a revision
> information, a date, a branch, a couple of properties, ...
>
> A "SourceStamp" object (from buildbot.sourcestamp import SourceStamp)
> define what will be built by gathering one or more mergeable "Source".
>
> Would it benefit to some other people to add a property about the
> repository path inside the "Source" object ? This would be making it
> completely self-defined: repository where it occured + what occured.
>
> I can imagine this information will be needed if buildbot is going
> toward a multi-repository support, at least for information/debugging
> purpose : knowing where did the Change came from.
>
> Then, we would just ask SourceStamp to gather the repositories path of
> the Source so that we can use it further inside buildbot for displaying
> or more. I, for instance, am using it as a property in one of my steps.

Yup. This sounds like a good plan!

I'm experimenting with mercurial subrepo builds and pushing changes from 
subrepos to buildsbot doens't work at the moment because revs there 
don't exist in the master repo. If the revision had a location/repo-path 
along with it, one could filter things (trigger a build, but with the 
default revision on master, and a specific on the subrepo.) and present 
the changes better.

I suppose svn:externals and git-ditto (and others) could benefit from a 
similar scheme. For that to succeed, knowing repo path for each change 
is important.

Thinking further, a location-mapper of some sort could go into 
WebStatus, as the repo-path could be file-local or use ssh, svn or 
git-protocols, but the web-view wants to use http(s).

> ----
>
> About the "category" support:
>
> "Source" can have a category attribute. I have a bad feeling about that
> one as it has to be configured by hand in the config script. One example
> of usage for this feature (category) you can find in the doc  is to set
> some builder as "test".
>
> This category has to be set via configuration, whereas this information
> (the repository path) is already self-contained in the repository
> itself, I am more in favor of using an existing property than having to
> specify it manually for each builder/source/...
>
> I hope I made my point more clear this time.

This is what my mental picture of category is too, currently at least. 
:) I.e. not repo-related, but to group builders per os, per 
type-of-build (doc, full, incremental) or similar things.

Only my 0.02 SEK, though.

Cheers,
/Marcus