Am 16.10.2013 08:33, schrieb simendsjo:
On Tue, 15 Oct 2013 18:53:12 +0200, Sönke Ludwig wrote:
Am 15.10.2013 17:34, schrieb simendsjo:
On Sat, 12 Oct 2013 17:59:03 +0200, Sönke Ludwig wrote:
(...)That was some time ago though, so there may be some more performance
regressions by now. I'll add a CI based performance test in a while to
stabilize performance over time.I have an Arch x86 Linode instance with a quite some spare resources if you need an extra CI node.
For vibe.d itself I already have a host running multiple VMs for that
purpose, but if you are willing to allocate some resources for a general
CI for all code.dlang.org projects at some point, that would definitely
be great!At least my suspicion is that we'll need to take everything we can,
depending on how much we'll want to test for each package.I'll probably need help configuring the server to run the testing sandboxed.
And the server only has 1GB RAM, which might be a problem..
But we can talk more about this when the time comes.Are you thinking of running an off-the-shelf CI? Does any have good D support?
It's a custom solution I'm currently working on, which is directly tied
to the combination git/DUB, so that it can basically be completely
configuration-free.
1GB RAM is probably an issue for a number of projects (since we don't
want to cause swapping on the server of course), but the CI master
server could be extended to assign workers based on its knowledge about
memory consumption for each package (it will monitor memory usage and
run time anyways). Then all high-memory consumption runs would happen on
some other server with more RAM.
Sandboxing is still my main concern, too. I don't really feel
comfortable running something like this just protected by a
non-privileged user account, when other, important things run on that
server.