#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 |
Cc: |
Description (last modified by dustin)
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
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
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}/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?
comment:5 Changed 7 years ago by dustin
In master/buildbot/status/web/base.py, 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/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?
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 base.py. 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 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!
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 base.py.
https://github.com/buildbot/buildbot/commit/118f679bd8a18af1f9889f97ccb00447ba0f66a4
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.
Tried with buildbot 0.8.8 packaged with Debian. Everything worked out of the box. My config is nothing special: