[Buildbot-devel] Help­ getting SVN step to work

Amy Troschinetz Amy.Troschinetz at adometry.com
Thu Jun 13 14:15:59 UTC 2013

On Jun 13, 2013, at 6:54 AM, vasslitvinov at pisem.net wrote:
> The problem here I think is you're mixing two different VC systems which have different meaning for "revision", and Buildbot has no idea about this.
> Thus when you do Mercurial step first Buildbot sets "got_revision" property to Mercurial revision (this long hex number), and then when you do SVN step it tries to use that revision as well and gets confused.
That's *very* surprising behavior. I didn't know that each step in a BuilderFactor wasn't independent from each other step. It seems odd because I'm sure I could workaround this issue by replacing the step

f.addStep(SVN(svnurl='https://paris:8443/svn/clickforensics/TRUNK/Common/Python', workdir='build/services/bin', mode='full', username='buildbot', password='bu1ldb0t'))

with the step

f.addStep(Test(command=['./somescript'], description=['update svn repo'], descriptionDone=['update svn repo']))

which runs a script that executes something like

cd /into/the/repository
svn update
exit 0

I would just prefer to do it the more robust/canonical way, which I would think would be to use the SVN class.
> There're several ways to overcome this.
> Easiest (IMO) might be to set "alwaysUseLatest=True" in SVN call, but that would still break the value of "got_revision" - SVN writes to that property as well. If you don't care about that I'd recommend you do so
This solution does seem to work! Much thanks.

> P.S. Maybe I'm completely wrong about the solution though because I'm not used to multi-codebase concept introduced by Buildbot guys in near past, maybe you should first read the manual about that…

You may be entirely correct, but the documentation is a bit unclear. I must also reiterate that even the need for such as concept as a "multi-codebase" and this the notion that special requirements need to be met to support it is surprising in the extreme. Yet I believe I have satisfied all the steps described here except for creating a codebaseGenerator.

In the documentation for the codebaseGenerator, there's this bit of code:

all_repositories = {
    r'https://hg/hg/mailsuite/mailclient': 'mailexe',
    r'https://hg/hg/mailsuite/mapilib': 'mapilib',
    r'https://hg/hg/mailsuite/imaplib': 'imaplib',
    r'https://github.com/mailinc/mailsuite/mailclient': 'mailexe',
    r'https://github.com/mailinc/mailsuite/mapilib': 'mapilib',
    r'https://github.com/mailinc/mailsuite/imaplib': 'imaplib',

The key values in this dict are clearly the repository paths, yet the semantics of the mapped values eludes me. Is that the user? What if we don't need a user? Is that the destination path of the checked out source? That doesn't seem right. Maybe those are the branches? What if we just want the default branch? I have no idea what those values are. Can anyone enlighten me?

Amy Troschinetz | Senior Software Developer | o 512.852.7127 | amy.troschinetz at adometry.com
Adometry | www.adometry.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20130613/5a1a55af/attachment.html>

More information about the devel mailing list