Opened 7 years ago

Closed 7 years ago

Last modified 6 years ago

#2586 closed defect (fixed)

Can't override html templates in master's templates directory

Reported by: hwoarang Owned by:
Priority: major Milestone: 0.8.9
Version: 0.8.8 Keywords: web

Description (last modified by dustin)


I am using 0.8.8 and I am not able to override the templates from /usr/lib64/python2.7/site-packages/buildbot/status/web/templates.

What I did was to copy the root.html file from there to my master's templates/ directory and do some minor edits. However, the web server still serves the one from the /usr/lib64/python2.7/site-packages/buildbot/status/web/templates directory.

The only way to make it load the one from my master's directory was to add the following in my masters.cfg file

import jinja2

myloaders = [

c['status'].append(html.WebStatus(http_port=8010, authz=authz_cfg, jinja_loaders = myloaders))

Adding this made buildbot pick the root.html file from my master's templates/ directory.

If you need more information please let me know

Change History (11)

comment:1 Changed 7 years ago by dustin

  • Keywords web added
  • Milestone changed from undecided to 0.8.9

comment:2 Changed 7 years ago by jollyroger

Tried with buildbot 0.8.8 packaged with Debian. Everything worked out of the box. My config is nothing special:

c['status'] = []

from buildbot.status import html
from buildbot.status.web import auth, authz
    gracefulShutdown = False,
    forceBuild = True,
    forceAllBuilds = False,
    pingBuilder = False,
    stopBuild = False,
    stopAllBuilds = False,
    cancelPendingBuild = False,

c['status'].append(html.WebStatus(http_port=8011, authz=authz_cfg))

comment:3 Changed 7 years ago by dustin

  • Description modified (diff)

hwoarang, is it possible you're using the wrong directory? The basedir isn't necessarily the directory containing buildbot.tac -- the TAC file can specify some other directory.

comment:4 Changed 7 years ago by hwoarang

buildbot.tac has the correct basedir setup in it. Could it be a problem with how the buildbot master is started in my distro (Gentoo?)

Here is the init script

start() {
        start-stop-daemon --start -u "${USERNAME}" \
                --pidfile "${BASEDIR}/" \
                --exec /usr/bin/python -- /usr/bin/twistd \
                --no_save \
                --logfile="${BASEDIR}/twistd.log" \
                --pidfile="${BASEDIR}/" \

where BASEDIR is the directory of where my master.cfg lives.

Apart from that I don't know what could it be wrong. Is there a way to debug (maybe a few lines of extra code) it in the buildbot core code and see which paths are search for extra templates?

comment:5 Changed 7 years ago by dustin

In master/buildbot/status/web/, modify createJinjaEnv to print os.path.join(os.getcwd().

comment:6 Changed 7 years ago by hwoarang

I added the following line to master/buildbot/status/web/

print "LOOKING TEMPLATES AT: "+os.path.join(os.getcwd())

And then

hwoarang@foo$ grep -r LOOKING twistd.log 2013-11-18 13:38:00+0000 [-] LOOKING TEMPLATES AT: /

It appears to me it's not looking properly

Maybe because buildbot is started using a init script (as shown before) and not directly from the master's directory?

comment:7 Changed 7 years ago by dustin

Oh, I remember this about Gentoo now that you mention it. It's odd, too, that Buildbot requires that the master's cwd be anything in particular.

So, I guess this can either be fixed in the initscript, in buildbot.tac, or in Which would you prefer?

comment:8 Changed 7 years ago by hwoarang

I personally wouldn't want this to be fix in the init script because Gentoo's init script is just one case of how one could launch a buildbot instance. Others may have their own script from launching buildmaster from anywhere.

I am not that familiar with the source code to suggest which one is better. buidlbot.tac or Maybe this should be in the instead? My personal preference would be to leave buildbot.tac as minimal as possible. But it's ultimately your call :)

Thanks for helping me debugging this!

comment:9 Changed 7 years ago by dustin

  • Resolution set to fixed
  • Status changed from new to closed

The bug really is in Gentoo - buildbot start sets the cwd correctly, and the initscript is attempting to emulate that command.

That said, I think you're right that it would be best to simply not rely on the cwd in

comment:10 Changed 6 years ago by cscott

I hate to be "That guy" who necroposts to a closed bug, but this is not fixed for me. There is still an instance of getcwd being used. I have submitted a pull request which fixes this issue for me in the "eight" branch. I have not tried master.

comment:11 Changed 6 years ago by sa2ajj

And now it's landed.

Note: See TracTickets for help on using tickets.