Message-ID: <1818616110.33943.1408765272706.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_33942_1014882712.1408765272705" ------=_Part_33942_1014882712.1408765272705 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The Groovy project currently makes use of the Codehaus architecture (Bam= boo) for continuous integration. Unfortunately, this infrastructure isn't s= ufficient for our needs: in order to further assess and improve the quality= of Groovy, we need to test builds on various systems (GNU/Linux, Windows, = Mac OS), multiple JDKs (from 1.5 to 1.8) and numerous branches, and the cur= rent infrastructure is neither fast and responsive enough, nor it allows us= to test and build Groovy in a sufficient number of different configuration= s and settings.
After having looked at various solutions (including famous CI server ven= dors and online services, which were either too slow or not supporting what= we need), we settled our mind on having a dedicated continuous integration= server. More precisely, we want to host a TeamCity build = server. For the rationale of choosing TeamCity, you can take a look below.<= /p>
Basically, the Groovy development team is looking for a sponsor = for such a server. The server will host several build agents itsel= f, so it needs both enough memory (8G to 16G) and a fast CPU (not overloade= d). Our idea is also to make possible for people to contribute buil= d agents, significantly improving the number of environments we wi= ll be able to test. This means the build server will host a lot of build re= sults, so at least 1TB of storage is mandatory.
An example of suitable server can be found here: http://www.online.net/fr/serveur-dedie/dedibox-lt (~50=E2=82=AC/mo= nth). (For administration, it is strongly preferred if the server is hostin= g GNU/Linux)
After having looked at various continuous integration servers, we found = that TeamCity had several advantages for our needs:
But more importantly, we plan to open the CI server to contributors, by = allowing them to run build agents on their idle systems. The idea is that p= eople would be able to run build agents on their computer, so that we have = an increasing number of environments available. One for example could run a= n agent on Windows, running JDK 8, while another would have Java 7 on Mac O= S, ...
TeamCity makes it very easy to distribute and contribute such agents, ma= king "hardware" contributions simple to the user and very interes= ting for us.