News | About | Get Frugalware | Packages | Documentation | Discussion Forums | Bug Tracker | Wiki | Community | Development

Syncpkg2

From FrugalWiki

Jump to: navigation, search

Contents

Architecture

syncpkgd

It runs on the master server and it has an interface (for example xml-rpc) to be controlled.

Basically it does nothing, just receives and posts messages between the clients (acts like a mailbox).

It receives messages from synchook and gives a pkg to syncpkgcds if they request one. It does not do anything if not reuqested.

syncweb

This is a web interface for syncpkgd. It can force the build of a package, abort the build of a package, monitor it, etc. Of course any modification needs authentication, viewing should be possible for anonymous users, too. Logs and statistics would be viewable to anonymous users.

syncpkgcd

This daemon runs on the build servers. When it starts, it registers itself to syncpkgd, so that when a new package is available for building, then it will get notified.

It receives other messages from syncpkgd, too so that syncpkgd can control syncpkgcd (abort the building of a package). Visiting the build server in a browser would simply forward you to the web interface running on the master server showing the stats page for that build server.

synchook

This is a small client that is called each time someone pushes a darcs patch. It checks if any package needs to be built and it'll perform a build request if it found something.

Communication protocol

I would propose xml-rpc but it can be something else, too. xml-rpc requres apache which is available on the master server and on the buildservers, too.

An other solution may use ssh since that's available everywhere, too.

Questions

Syncpkgd1 tries to build a failed package again and again. This may sound stupid, but sometimes very useful. I think syncpkgd2 should notify the maintainer in case the build failed, this way we could stop trying building a package after it failed once. Or is there any other solution?

  • It should always notify the maintainer upon a build failure, yes. --AlexExtreme 11:10, 28 April 2007 (CEST)

An other problem is that this way we can still miss some packages, how to detect them? What about having a test in the testsuite for packages not built for more than <some time, like 2 days>?

Personal tools
Namespaces
Variants
Actions