>> Do I miss something here, or is the buildbot hit by spammers now?
>
> It looks like it is. If that continues, we have to disable the web
> triggers.
Good grief. If anyone has any bright ideas about simple ways to change that
form to make it less vulnerable to the spambots, I'd be happy to incor
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
>> But I agree that
>> getting regular builds running would be a good thing. An x64 box
>> would be ideal to build both the x86 and x64 versions on. A single
>> bot can manage many platforms, right?
>
> A single machine, and a single buildbot install
"Gregory P. Smith" <[EMAIL PROTECTED]> writes:
> as for buildbot, i haven't looked at its design but from the chatter
> i've seen i was under the impression that it operates on a continually
> updated sandbox rather than a 100% fresh checkout for each build?
It's a configuration option. If you us
> I still haven't figured out how to mutually lock out builders that are
> on the same slave. This is a frequent thing to happen, as people often
> check-in trunk and backported branch patches nearly simultaneously
> (which is fine, of course - the machines just have to cater with that).
You can t
> PS If there was a method on ShellCommand, adding a step would be simpler,
> e.g.,
>
> def addStep(self, cls, **kwds):
> self.steps.append((cls, kwds))
Ooh! I like that.
> then we could do: f.addStep(Catalog, command=Catalog.command)
It would be even simpler: f.addStep(Catalog). The comma
> nice-ing the slave process at startup would be the way to do it, right?
Yup. We run the twisted buildslaves under 'nice', and it works pretty well.
It also reveals problems in tests that use absolute timeouts which fail when
the test runs slower than the author thought it was supposed to.
cheer
> The reason I want static pages is for security concerns. It is not
> easy whether buildbot can be trusted to have no security flaws,
> which might allow people to start new processes on the master,
> or (perhaps worse) on any of the slaves.
These are excellent points. While it would take a compl
> > Ah, but that would require changes to the slaves, right? I would
> > prefer a solution that avoids that.
>
> I don't think so. In my little test setup I didn't have to make any
> change to the slave.
The "update" and "clobber" mode parameters are implemented on the slave side.
Trent's patch c
> > > To wipe out the build occassionally you could (presumably) add a
> > > starting step to the Python 'builder' (in the build master.cfg) to
> > > rm -rf $builddir
> > > every, say, Sunday night.
That would work, although to be honest the buildbot is more about repeatable
builds. My first
> I have security concerns as well, but not in buildbot itself. My
> project is restricted even withinz the company I work for so I need
> the buildbot web server to only be available to certain people.
> HTTPS access would be nice too. TwistedWeb doesn't seem to have
> support for eithe
> For this part at least, it's easier than that; you can pass
> interface='127.0.0.1' to the relevant listenTCP or TCPServer call, so that it
> will only bind that port to localhost.
And I intend to add an option to the buildbot master.cfg file to make it easy
to do just that. It should be in the
> From: "Martin v. Löwis" <[EMAIL PROTECTED]>
>
> So at the moment, I'm quite happy with buildbot. My only wish is that
> it would do static pages, rather than being a web server. I set it up
> as a reverse proxy (so nobody knows what the port number is, but still).
As a bit of history, the build
> Currently, branches are not supported, because buildbot is
> somewhat limited. When I get a solution for this problem,
> I plan to have all buildbots build both the trunk and the
> 2.4 branch; such builds would only be initiated whenever
> something is committed on the branch.
Branch support app
13 matches
Mail list logo
