{5} Assigned, Active Tickets by Owner (Full Description) (25 matches)

If the slave directory has spaces in it, BB gets completely confused if following  http://trac.buildbot.net/wiki/RunningBuildbotOnWindows

It appears that the directory gets broken up on space boundaries, and if you explicitly add double-quotes to prevent that, the entire string (including quotes) is interpreted as a path _relative_ to buildbot's installation in site-packages/

That wiki page should include 2 prominent warnings about this pitfall until the actual problem is fixed.

Brian Warner wrote:

On Sat, 24 Nov 2007 13:06:32 -0500 "Sergey A. Lipnevich" wrote:

In 0.7.6, adding log observer that produces new metrics is tricky because each new metric must be also mentioned in build step's progressMetrics member. Would it be better instead to declare all metrics provided by log observer in its class, and automatically add new metrics names to progressMetrics once the observer instance is added? I can file a ticket and submit a patch, I'm asking here first if it's a good idea to make this change.

I think that's a good idea. You'll need to double-check that the "expectations" are still filled in correctly.. it's been a long time since I looked at that code, but I seem to remember there is a place where we run through all steps and fill them with expectations from the previous build. We'd need to make sure that we enumerate the metrics before doing this setting-expectations phase.

This morning I ran into a very big issue with the way buildbot do a Mercurial checkout.

Here is the context :

• The repository contains a named branch

• A tag has been set on a revision of that branch

• From the buildbot web ui, we force a build with the tag as the revision

• buildbot do a "hg clone --rev THETAG <url>"

• The actual current changeset of the clone after checking out is NOT the revision corresponding to the tag. Instead it update to the latest revision that is on the "default" branch.

In the end the build is not done on the correct revision.

I suggest not to rely on the "clone --rev" but rather do a "pull" followed by a "update -r". Additional reasons for that :

• It will be way faster for big repositories (ours is ~130M).

• When using clone --rev, the tag is "lost" because the .hgtags file is set in a later changeset than the tagged changeset.

Note that I have reproduced the issue with buildbot 0.7.9 and 0.7.10, and Mercurial 1.0.1 and 1.1.2

the 'svn export' command isn't being run with _dovccmd, so it's not getting the username attached.

This most readily manifests itself when running the svn export step in a build started by the anybranch scheduler, triggerable scheduler or by rebuilding.

 Perforce path can be specified in "client syntax". Currently P4Source's p4base argument seems to expect "depot syntax".

Right now, p4base argument is used for two different things: as an argument to "p4 changes", and to filter output of "p4 describe". The first can be in any syntax, but the second must be in depot syntax since that's what Perforce outputs. So if one specifies p4base in client syntax, no output matches and no change is added. I think two should be specified by two separate arguments, probably with a sensible default.

I learned about a few tools at PyCon? that may be useful for this purpose. First, we should document these tools in the developer documentation so that others can work with them, too. Second, we should apply them in development to see if there are any low-hanging fruit in terms of memory consumption.

• sys.getsizeof (2.6 only)
• Meliae - dumps a reference graph in JSON
• gdb-heap - dumps the Python heap in GDB (mostly totals)

When I was creating a development environment for buildbot nine, I installed buildbot-www using 'python setup.py install'. However, if I tried to create a master using that setup I hit the following traceback:

(sandbox)[tflink@localhost buildbot_work]$ buildbot create-master master
mkdir /home/tflink/buildbot_work/master
creating /home/tflink/buildbot_work/master/master.cfg.sample
populating public_html/
populating templates/
Traceback (most recent call last):
  File "/home/tflink/buildbot_work/sandbox/lib/python2.7/site-packages/twisted/internet/defer.py", line 1214, in unwindGenerator
    return _inlineCallbacks(None, gen, Deferred())
  File "/home/tflink/buildbot_work/sandbox/lib/python2.7/site-packages/twisted/internet/defer.py", line 1071, in _inlineCallbacks
    result = g.send(result)
  File "/home/tflink/buildbot_work/src/master/buildbot/scripts/create_master.py", line 145, in createMaster
    yield createDB(config)
  File "/home/tflink/buildbot_work/sandbox/lib/python2.7/site-packages/twisted/internet/defer.py", line 1214, in unwindGenerator
    return _inlineCallbacks(None, gen, Deferred())
--- <exception caught here> ---
  File "/home/tflink/buildbot_work/sandbox/lib/python2.7/site-packages/twisted/internet/defer.py", line 1071, in _inlineCallbacks
    result = g.send(result)
  File "/home/tflink/buildbot_work/src/master/buildbot/scripts/create_master.py", line 128, in createDB
    master = BuildMaster(config['basedir'])
  File "/home/tflink/buildbot_work/src/master/buildbot/master.py", line 82, in __init__
    self.create_child_services()
  File "/home/tflink/buildbot_work/src/master/buildbot/master.py", line 146, in create_child_services
    self.www = wwwservice.WWWService(self)
  File "/home/tflink/buildbot_work/src/master/buildbot/www/service.py", line 36, in __init__
    for ep in pkg_resources.iter_entry_points('buildbot.www') ]
  File "/home/tflink/buildbot_work/sandbox/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg/pkg_resources.py", line 1954, in load

  File "/home/tflink/buildbot_work/sandbox/lib/python2.7/site-packages/buildbot_www-0.8.7p1_778_g98e77e1-py2.7.egg/buildbot_www.py", line 59, in <module>
    ep = Application()
  File "/home/tflink/buildbot_work/sandbox/lib/python2.7/site-packages/buildbot_www-0.8.7p1_778_g98e77e1-py2.7.egg/buildbot_www.py", line 52, in __init__
    self.version = open(verfile).read().strip()
exceptions.IOError: [Errno 2] No such file or directory: '/home/tflink/buildbot_work/sandbox/share/buildbot/dist/buildbot-version.txt'

Once I installed buildbot-www with pip, I was able to create a master without issue

I'd like to be able to associate builders to multiple categories, so they can appear in multiple views in the web status UI. (I'e like to classify along multiple axes, such as "internal" vs. "public", as well as "stable" vs. "devel".

We run a few different buildmasters -- they're monitoring different repos, and in general are for different teams. But we use the same (large) set of build VMs for both. Currently we run two buildslave instances on each build VM, which is inefficient in a few ways: it's a lot of duplicated data in RAM, since Python bytecode isn't shared the way .so's are; and it means that builds for two different projects can be taking place simultaneously on the same VM.

It would be nice to have the option of pointing a single buildslave at multiple buildmasters, with some sort of locking to only allow it to run a single build at a time.

Buildbot currently records the start/end time for steps on the master. This means that end time of step N is always the same as the start time of step N+1.

When master load is high, the latency between a slave actually finishing a command and receiving the next one can be significant.

One idea is to have the slaves record the command start time internally, and then when the command is done, send the slave start/end time to the master. The master would use its version of the start time as the step start time, and then calculate the delta between slave start time as master start time as clock scew/network latency and add it to the slave's end time.

The buildbot slave default timeout can be too short for us. Sometimes, 5sec isnt always enough, and we get following:

% cltbld$ buildbot start /Users/cltbld/macosx-slave1

Following twistd.log until startup finished.. The buildmaster took more than 5 seconds to start, so we were unable to confirm that it started correctly. Please 'tail twistd.log' and look for a line that says 'configuration update complete' to verify correct startup.

%

... even though slave started "normally", responds fine to pings from buildbot master, and does handle jobs just fine.

If different webstatus instances are available to different people, they should get different force build options.

Some things would be made easier if we were to store build status in a database that could be read by other processes. SQLite would be a good starting point.