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

[hwoarang]

Hi,

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 = [
        jinja2.FileSystemLoader(dirname(__file__)+"/templates"),
]

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

[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
authz_cfg=authz.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))

[dustin]

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.

[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}/buildmaster.pid" \
                --exec /usr/bin/python -- /usr/bin/twistd \
                --no_save \
                --logfile="${BASEDIR}/twistd.log" \
                --pidfile="${BASEDIR}/buildmaster.pid" \
                --python="${BASEDIR}/buildbot.tac"
}

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?

[dustin]

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

[hwoarang]

I added the following line to master/buildbot/status/web/base.py

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?

[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 base.py. Which would you prefer?

[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 base.py. Maybe this should be in the base.py 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!

[dustin]

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 base.py.

​https://github.com/buildbot/buildbot/commit/118f679bd8a18af1f9889f97ccb00447ba0f66a4

[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.

​https://github.com/buildbot/buildbot/pull/1851

[sa2ajj]

And now it's landed.