Ticket #44 (new defect)

Opened 1 year ago

Last modified 1 year ago

can buildbot generate static html file not dynamic page?

Reported by: joduinn Assigned to:
Priority: major Milestone: 0.8.0
Component: statusplugins-web Version: 0.7.5
Keywords: Cc: Pike, joduinn

Description

Carried forward from sourceforge.net ticket#1517950.

1) security problems, sometimes we dont want the buildmaster to be visible to the outside world, even though we want the status of buildmaster to be visible.

2) load problems, it takes time from buildmaster to answer all the http requests. The extra traffic load might overrun the buildmaster on larger sites.

Change History

06/20/07 02:28:01 changed by Pike

  • cc set to Pike.

Heres the ticket on sf.net.

One thing that I wondered about would be build logs. buildbot's http server feeds those out as they come in, which is nice, no idea how to make that in a static case. And the build logs need to be exported to the output, too.

I'm personally not too fond of doing this, btw, as it basically locks down the output format. But I do think that the load problem in particular needs to be solved.

06/21/07 17:48:25 changed by joduinn

  • cc changed from Pike to Pike, joduinn.

07/02/07 18:58:23 changed by warner

  • component changed from buildprocess to statusplugins.
  • milestone set to 0.8.0.

yeah, logfiles would just need to be dumped to disk pre-formatted. We could rig up a subscriber on the LogFile? object to write (and probably flush) the HTML to disk as the chunk arrived, so a browser could see content before the step had finished, but I suspect it would look truncated, so you'd have to hit reload a lot to follow along.

The way to approach this feature has two parts to it. The first is to identify all the pages that you want available statically, find the code in buildbot/status/web/waterfall.py that is used to construct their HTML, and refactor it so it can be called from somewhere else (that means changing the functions to accept a file-handle-like object and have them write their HTML to that). These functions should be set up to accept an I*Status-providing object as input (i.e. the code that generates logfiles should accept an IStatusLog for input and a filehandle as output).

The second part is to write a status plugin that subscribes to hear about new builds and steps and logs, have it decide where on disk the HTML for each of these things should go, then have it use those HTML convertor functions to pull the relevant information out of the I*Status objects and write it out to disk.

07/30/07 19:29:45 changed by warner

  • owner deleted.
  • component changed from statusplugins to statusplugins-web.