We have a buildbot

[Z-Man]

You should probably clean up your system a bit

write error: No space left on device

[Lucifer]

Man, I did clean it up! Grrr........

Edit:

Code: Select all

Filesystem            Size  Used Avail Use% Mounted on
/dev/hda2              17G  5.5G   11G  35% /
/dev/hda5             278M  3.3M  261M   2% /boot
/dev/hda7             897M  848M  1.5M 100% /home
/dev/hda8              37G   16G   19G  46% /home/share

It's building on /home/share. 19G free.

[Lucifer]

Working on the buildbot again.

http://waterfall.davefancella.com/

So, we've got new options. To watch the source for changes, we can use svn like we did before, or we can ask everybody to install the buildbot hook to their bzr installation. Is it possible to install bzr hooks by having them present in the repository instead?

Also, buildbot has special support for pqm.

So, hm. I'm a little lost on how to set it up for branches this time. For some reason, I'm wanting to just have separate builders for each branch. Normally, of course, you associate builders with targets, and whenever a branch has changes, every builder tries to build its target.

I'm also at a bit of a loss as to how to get it to build using the build-tools module so we can have packages built and uploaded to aabeta.

Finally, anybody willing to volunteer a windows build slave this time?

[Lucifer]

Ok, buildslaves are much easier to setup now. I'll go update the wiki docs on the subject.

[Z-Man]

Does the machine hosting the buildslave need to be on 24/7 or will it, if it's only booted every once in a while, be smart enough to fetch the latest thing to build and build that as soon as you turn it on? (Can't host a Windows buildslave right now, I'm still on codeblocks 1.0.rc2 for the 0.2.8.3 builds. Not a good time to switch. But if I would host it, it'd only run sporadically.)

About the updates from bzr: can't you just subscribe to the branches on launchpad? That's what I do with bazaarmagetron, it gets change notices by mail.

Also, what was the main purpose here again? Was it to check whether our builds work? In that case, we don't need a Windows buildslave. Sure, the build breaks on a regular basis whenever files are added. But those are always easy to fix and don't stop any Windows developer from doing his work because a) they're easy to fix and b) we don't have a Windows developer currently. What we should concentrate on instead is the various build configurations we have to support. Is the purpose to get current builds out to the users? Then nightly tarballs and builds from those would probably be better, this would increase the value of incoming bug reports from those versions.

[Lucifer]

Does the machine hosting the buildslave need to be on 24/7 or will it, if it's only booted every once in a while, be smart enough to fetch the latest thing to build and build that as soon as you turn it on? (Can't host a Windows buildslave right now, I'm still on codeblocks 1.0.rc2 for the 0.2.8.3 builds. Not a good time to switch. But if I would host it, it'd only run sporadically.)

It will attempt every build that was triggered when it was off. So it needs to be on often enough that it doesn't develop too much of a backlog.

It can also be setup to run only when certain other builds succeed. So we could say "only if the generic linux build succeeds, then run all the other builders". Most problems that may come up should be revealed in the generic linux build, since we have few platform-specific problems.

About the updates from bzr: can't you just subscribe to the branches on launchpad? That's what I do with bazaarmagetron, it gets change notices by mail.

I can give that a try. There is an email poller. Maybe it would be better to just do a regular nightly build with the latest revision?

Also, what was the main purpose here again? Was it to check whether our builds work? In that case, we don't need a Windows buildslave.

Lots of potential uses. The first original goal was to check the server build, because at the time there was a tendency to do client-side work that broke the server and forget to test the server, which caused anybody who wanted to work on the server to first fix that, or be unable to work. Then there's:

* Run regular tests and report the results (right now just distcheck and installcheck, but when/if we get a real testing suite, it would run that, too)
* Automated builds for people who want to run bleeding edge and help with bug reports and stuff, but can't build for whatever reasons
* Provide a mechanism that allows developers to work on specific platform problems without requiring them to possess the platform (basically, linux developers get to make sure they can build in windows).

The real benefits, though, I think, are in running tests. So we need tests to enjoy those benefits. That's what buildbot is typically used for, running regression tests.

[Z-Man]

Umm, I boot into Windows once or twice per week. I definitely won't be able to run a buildslave in 'work up all your backlog' mode. I get why it's doing that (to pinpoint the exact revision that broke stuff), but it'd half block my computer for hours. Fully block it for development work. Last time I checked, Code::Blocks was one of those retarded programs you can only run one instance of at a time. At least per user.

The real benefits, though, I think, are in running tests. So we need tests to enjoy those benefits. That's what buildbot is typically used for, running regression tests.

Right. That. I think Linux buildslaves perfectly suffice for that. The tests won't be system dependant. We can still supply our users with up to date Windows builds with less of an infrastructure behind it if we manage to automate the process.

[Lucifer]

Yay for bringing back old threads.

So, I'm working on a buildbot again. I think I'll use the daily scheduler thing, but I haven't set it up that way yet.

Rereading some of this thread (it's a bunch of obsolete technical stuff), I think we should aim for nightly snapshots zipped that run in a directory, none of this create packages crap.

Might use nsh22's server to host the snapshots?

It's not ready for production use yet.

[Jip]

CloudBees have a FOSS program where they offer free service for open source software:
https://www.cloudbees.com/resources/foss/

[Z-Man]

Wouldn't it be less work intensive if I checked how the build process I have been using for a while works? It was running in nice, stable virtual machines and used cross compilation via Wine for the Windows builds. Of course, I expect the Windows builds to be badly broken at this point.

[Tank Program]

If it wasn't Windows we were talking about, we could just create/make an up to date virtual machine, image it, and share the image. *sigh*

[Light]

If it wasn't Windows we were talking about, we could just create/make an up to date virtual machine, image it, and share the image. *sigh*

If WINE don't have a problem compiling it, you could hit two in one on Linux. I assume Z-Man was saying it worked that way? Bash + cron

[Lucifer]

Wouldn't it be less work intensive if I checked how the build process I have been using for a while works? It was running in nice, stable virtual machines and used cross compilation via Wine for the Windows builds. Of course, I expect the Windows builds to be badly broken at this point.

That would help, at least. Since I don't know how we're building it in Windows. I can probably offer a buildslave running wine, since it'll be running in the middle of the night.

In terms of work intensive, the biggest problems I'm having involve buildbot's API and stuff like that. I think I have a nearly finished builder setup for POSIX systems. Once those builders can upload to a website, the builder is done (barring changes in build procedure).

[Jip]

I also can offer a build slave if needed.

[Lucifer]

I also can offer a build slave if needed.

For what platform? I'm currently trying to determine if the buildbot uses all available slaves for each builder, or if it only uses one at a time. Makes sense that it would only use one at a time, so redundant slaves would reduce the workload suffered by any one slave.

One thing that's changed since the last time we had a buildbot, access to the repository is now run through the build master, rather than having individual machines do a checkout. I like the ease of use it gives, but I'm concerned about the bandwidth required if we have a large collection of slaves.

But I'm sure we can find a server somewheres on the internets that can run the master, if need be.