[Buildbot-devel] User/pass authentication in buildbot.step.source SVN

Degremont, Guillaume guillaume.degremont at hp.com
Fri Feb 1 10:39:42 UTC 2008


I am trying to setup a buildbot. My source code is located in a svn repository, which requires authentication for checkout.

Reading from buildbot/steps/source.py, it seems that the username/password is not handled in the SVN class.
I am a newbie to python, but I tried to create a class Authenticated_SVN(SVN), with the __init__ handling the storage of username and password. In the startVC, I first tried to add the username and the password in the self.args dictionnary that is transmitted to the LoggedRemoteCommand, but it failed.

I then tried to replace the "svn" passed to LoggedRemoteCommand, with "snv --username %s --password %s". And it still failed.

Can anyone help me ?

And by the way, is there a reason why the user/pass authentication is implemented in the svnPoller but not in the SVN ? (maybe there is a good reason I missed)

Best regards,

Here is the code of my class and how I use it:
class Authenticated_SVN(SVN):
    def __init__(self, svnuser, svnpasswd, **kwargs):
        @type  svnuser: string
        @param svnuser: the user name used to authenticate to the svn base

        @type  svnpasswd: string
        @param svnpasswd: the password used to authenticate to the svn base
        self.svnuser = svnuser
        self.svnpasswd = svnpasswd
        SVN.__init__(self, **kwargs)

    def startVC(self, branch, revision, patch):

        # handle old slaves
        warnings = []
        slavever = self.slaveVersion("svn", "old")
        if not slavever:
            m = "slave does not have the 'svn' command"
            raise BuildSlaveTooOldError(m)

        if self.slaveVersionIsOlderThan("svn", "1.39"):
            # the slave doesn't know to avoid re-using the same sourcedir
            # when the branch changes. We have no way of knowing which branch
            # the last build used, so if we're using a non-default branch and
            # either 'update' or 'copy' modes, it is safer to refuse to
            # build, and tell the user they need to upgrade the buildslave.
            if (branch != self.branch
                and self.args['mode'] in ("update", "copy")):
                m = ("This buildslave (%s) does not know about multiple "
                     "branches, and using mode=%s would probably build the "
                     "wrong tree. "
                     "Refusing to build. Please upgrade the buildslave to "
                     "buildbot-0.7.0 or newer." % (self.build.slavename,
                raise BuildSlaveTooOldError(m)

        if slavever == "old":
            # 0.5.0 compatibility
            if self.args['mode'] in ("clobber", "copy"):
                # TODO: use some shell commands to make up for the
                # deficiency, by blowing away the old directory first (thus
                # forcing a full checkout)
                warnings.append("WARNING: this slave can only do SVN updates"
                                ", not mode=%s\n" % self.args['mode'])
                log.msg("WARNING: this slave only does mode=update")
            if self.args['mode'] == "export":
                raise BuildSlaveTooOldError("old slave does not have "
            self.args['directory'] = self.args['workdir']
            if revision is not None:
                # 0.5.0 can only do HEAD. We have no way of knowing whether
                # the requested revision is HEAD or not, and for
                # slowly-changing trees this will probably do the right
                # thing, so let it pass with a warning
                m = ("WARNING: old slave can only update to HEAD, not "
                     "revision=%s" % revision)
                warnings.append(m + "\n")
            revision = "HEAD" # interprets this key differently
            if patch:
                raise BuildSlaveTooOldError("old slave can't do patch")

        if self.svnurl:
            assert not branch # we need baseURL= to use branches
            self.args['svnurl'] = self.svnurl
            self.args['svnurl'] = self.baseURL + branch
        self.args['revision'] = revision
        self.args['patch'] = patch

        revstuff = []
        if branch is not None and branch != self.branch:
        if revision is not None:
            revstuff.append("r%s" % revision)
        if patch is not None:

        ## first try, failed spectacularly
        #self.args['username'] = self.svnuser
        #self.args['password'] = self.svnpasswd
        #cmd = LoggedRemoteCommand("svn", self.args)

        ## second try, failed too :/
        svn_string = "snv --username %s --password %s " % (self.svnuser, self.svnpasswd)
        cmd = LoggedRemoteCommand(svn_string, self.args)
        self.startCommand(cmd, warnings)

mybuildFactory.addStep(Authenticated_SVN(svnuser=svnuser, svnpasswd=svnpass, baseURL=svnurl+'/', defaultBranch='trunk', mode='update'),haltOnFailure=True)

Here is my error log:

2008/02/01 12:33 +0200 [Broker,0,] Build.setupBuild failed
2008/02/01 12:33 +0200 [Broker,0,] Unhandled Error
        Traceback (most recent call last):
          File "/usr/lib/python2.4/site-packages/twisted/internet/defer.py", line 239, in callback
          File "/usr/lib/python2.4/site-packages/twisted/internet/defer.py", line 304, in _startRunCallbacks
          File "/usr/lib/python2.4/site-packages/twisted/internet/defer.py", line 317, in _runCallbacks
            self.result = callback(self.result, *args, **kw)
          File "/usr/lib/python2.4/site-packages/buildbot/process/builder.py", line 616, in _startBuild_2
            d = build.startBuild(bs, self.expectations, sb)
        --- <exception caught here> ---
          File "/usr/lib/python2.4/site-packages/buildbot/process/base.py", line 300, in startBuild
            self.setupBuild(expectations) # create .steps
          File "/usr/lib/python2.4/site-packages/buildbot/process/base.py", line 351, in setupBuild
            step = factory(**args)
        exceptions.TypeError: __init__() takes exactly 3 non-keyword arguments (1 given)

More information about the devel mailing list