[Buildbot-devel] Apache aliases and getURLForThing

[Daren Grant]

Grig wrote ...
    > 
    > I have this scenario in the Pybots buildbot farm: there are 2
Python
    > branches that are being built, 'trunk' and '2.5'. The builder
names
    > are 'slavename' + 'branch name' -- for example 'x86 Ubuntu Breezy
    > trunk'. The Waterfall setup is the following:
    > 
    > portBase = 9060
    > for i, categories in enumerate([None, 'trunk', '2.5']):
    >     http_port = 'tcp:%d:interface=127.0.0.1' % (portBase + i)
    >     kwds = {}
    >     if categories:
    >         kwds['categories'] = categories
    >    status.append(html.Waterfall(http_port=http_port,
    > allowForce=allowForce,
    >                                 css=buildbot_css, **kwds))
    > 
    > The buildbotURL is:
    > 
    > c['buildbotURL'] = "http://www.python.org/dev/buildbot/community/"
    > 
    > There are also Apache aliases setup so that
    > http://www.python.org/dev/buildbot/community/trunk/ shows the
builders
    > for the trunk and similarly for 2.5.
    > 
    > The problem is that getURLForThing returns URLs of the form:
    > 
    >
http://www.python.org/dev/buildbot/community/x86%20Ubuntu%20Breezy%20t
    > runk/builds/280/step-nose
    > 
    > which are invalid, because they don't contain the branch name
(trunk)
    > after buildbotURL. The correct URL in the case above would be:
    > 
    >
http://www.python.org/dev/buildbot/community/trunk/x86%20Ubuntu%20Bree
    > zy%20trunk/builds/280/step-nose
    > 
    > I hacked the mail notification module and added the branch names
after
    > buildbotURL so that the links included in the notification emails
are
    > correct. But it's an ugly hack. And now I need to hack the modules
    > that handle build details too.
    > 
    > My question is if there's any way to inform getURLForThing about
    > branch names, maybe via categories, so I don't have to resort to
these
    > hacks?
    > 
    > Grig
    > 

Grig, 

I had similar issues having several buildbot category waterfall
displays.
I cannot remember for the life of me which one of these fixed the issue,
but here is a rundown of my working setup.

1 Waterfall is configured with all the categories on port BASE_WATERFALL
( port 8022 ) its one huge page and very messy, but I think its needed.

Additional waterfalls are specified with each of their categories on
ports BASE_WATERFALL + an offset

The buildbot URL configuration in my master.cfg is 

C['buildbotURL'] = "http://buildbot.mydomain.com:/All/"


My Apache configuration for the Virtual Host "buildbot" contains ... 

    ProxyPass /All/ http://myserver.mydomain.com:8022/
    ProxyPassReverse /All/ http://myserver.mydomain.com:8022/

    ProxyPass /Trunk/ http://myserver.mydomain.com:8023/
    ProxyPassReverse /Trunk/ http://myserver.mydomain.com/8023/

    And so on for each waterfall 

I additionally have some redirects like

Redirect /Trunk http://buildbot.mydomain.com/Trunk/
Just to allow people to go to the status page without the need for the
trailing /

I think the solution comes from a combination of the  c['buildbotURL']
being having an extra level from the base URL , and the Fwd and Reverse
Proxies.

As a warning I do not have to be secure on my server as it is only
accessed from an internal network, hence I cannot make any statement as
to the security of using the ProxyPass declarations.

I hope this helps.

Daren