On Oct 25, 2009, at 2:32 PM, Martin v. Löwis wrote: >> I've been trying to get some feedback about firing up buildbots on >> Cloud >> Servers for a while now and haven't had much luck. I'd love to >> find a >> way of having buildbots come to life, report to the mother ship, do >> the >> build, then go away 'till next time they're required. > > I'm not quite sure whom you have been trying to get feedback from, and > can't quite picture your proposed setup from above description. I posted a couple of messages on testing-in-python, and have sent around some queries to others that I know are using buildbot type setups with various tools/platforms, not necessarily Python. > In any case, ISTM that your approach isn't compatible with how > buildbot > works today (not sure whether you are aware of that): a build slave > needs to stay connected all the time, so that the build master can > trigger a build when necessary. > > So if your setup requires the slaves to shut down after a build, I > don't > think this can possibly work. It can't possibly work within the way the Python buildbot structure currently works, as I understand it so far. What I'm implementing is less of a 'continuous integration' tool like you would use for something like Python itself, and more of a testing tool for things that have to be installed on multiple versions of Python, on multiple platforms. I don't need to know that it works on every checkin, just every once in a while I'd like to start from scratch and make sure everything still works on all supported versions of Python on all the platforms I test on and cloud servers are great for this since I'll usually only need them for an hour or so. S
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4