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

Jared Grubb jared.grubb at gmail.com
Fri Jun 14 01:11:43 UTC 2013

On Jun 13, 2013, at 7:15, Amy Troschinetz <Amy.Troschinetz at adometry.com> wrote:

> 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

Actually, if you have two source steps in a single build (eg, one SVN and one Mercurial), then you must use the 'codebase' feature of buildbot (which was added in 0.8.7 if I remember right). Otherwise, the single got-revision will get clobbered and things will get very confused.

If you're trying to do two source steps prior to 0.8.7, you'll get a headache :)



> 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
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
> Build for Windows Store.
> http://p.sf.net/sfu/windows-dev2dev_______________________________________________
> Buildbot-devel mailing list
> Buildbot-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/buildbot-devel

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

More information about the devel mailing list