[Buildbot-devel] multi-repo support: repo URLs

[Benoît Allard]

Hi there,

Dustin J. Mitchell wrote:
> On Sun, Apr 11, 2010 at 6:41 AM, Tobias Oberstein
> <tobias.oberstein at tavendo.de> wrote:
>> As said, I think the fully qualified repo URL should be part of a change,
>> since together with branch/revision, it uniquely identifies the change.
> 
> Agreed, and this bears repeating :)
>> This means e.g. that the sourcestamp stored in the database does not contain the
>> fully qualified repo URL.
> 
> I see this as a problem, too.
> 
>> If the hook doesn’t send the fully qualified URL, then I think the right place
>> to derive the fully qualified URL is not the build step, but the change source.
> 
> We should never be putting substrings into the repository property.
> If a Change or SourceStamp has a nonempty repository attribute, it
> should be a complete pointer to the code.  Again, you can do whatever
> you want in the privacy of your project, but in terms of Buildbot's
> design, let's keep it simple.
> 

I don't know what to think about that. We all agree that this 
information helps us making the SourceStamp unique. Only unique, in 
which context ?

My understanding is that it should be enough to describe a Change within 
your current namespace. In a corporate environment, for instance, 
according to me, the substring is enough. However, in a public project, 
it might make sense to have the full path there, but then, what happen 
if you move the repository ?

> The problem that you and Ben are addressing is that the origin of the
> Change may not be the best place to get the code, especially in a DVCS
> situation.  Concretely, if I commit to a local git repo, the
> repository string
> 
>   /home/dustin/projects/amanda/
> 
> is not particularly helpful on some other system.  So the issue is one
> of recognizing "equivalent" repositories, and perhaps substituting a
> canonical repository for its equivalents.

In your case, in your environment (defined in our case via your buildbot 
config file), I guess "amanda" uniquely defines your repository. My 
advice would be for the ChangeSource step to only return "amanda" in you 
case, as this is the only value making sense for your master. Let the 
master then add his knowledge to this value, making it absolute within 
your current config.

 > *This* can be done at the
> ChangeSource level, but I think that we will quickly find
> %-substitution too limiting.

The doc you linked to in a previous mail has some more evolved options: 
you can give him a callable for instance, and in that case do the magic 
you want. It is still limited to the repository path though.

 > Rather, let's add a "canonicalize"
> function to the changesources that can perform whatever munging is
> approrpriate (and not just on the repository).
> 

If I get it correctly, you want to move the modifications we (Marcus and 
I) made lastly into an earlier stage: move them from the webstatus and 
the source step to the ChangeSource step. No objections from my part as 
long as it stays as flexible as we made it.

Regards,
Benoît

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6031 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://buildbot.net/pipermail/devel/attachments/20100412/1faac64a/attachment.bin>