Difference between revisions of "Buildslave Warszawa"
|Line 16:||Line 16:|
=== CMake_x86_MSVCWin Debug ===
=== CMake_x86_MSVCWin Debug ===
A variant of CMake branch builder, which is using MSVC compiler and build tools, instead of GCC. Not producing any ISOs yet, due to ongoing works on porting ReactOS code to MSVC. It can be only triggered manually, by passing 'revision' number. This builder 'source' parameter value is: '
A variant of CMake branch builder, which is using MSVC compiler and build tools, instead of GCC. Not producing any ISOs yet, due to ongoing works on porting ReactOS code to MSVC. It can be only triggered manually, by passing 'revision' number. This builder 'source' parameter value is: ''.
=== NewCC_x86_GCCWin ===
=== NewCC_x86_GCCWin ===
Revision as of 09:34, 10 July 2011
The Buildslave Warszawa is a multi-purpose buildmachine, focused on aiding ReactOS development. Currently it hosts multiple builders, albeit only the one building ReactOS Trunk in debug mode is attached to scheduler and triggered automatically. Others need to be triggered by hand when needed.
Motherboard: EVGA X58-SLI-LE Processor: Intel i7 920 @ 2.67Ghz (Bloomfield 1366) Memory: Triple Channel G-Skill PC3-10700H, 3x 2GB + 3x 1GB Mass storage: Samsung SpinPoint F3 1TB, 7200rpm, 32MB cache (1x OS, 2 in RAID 0)
Triggered by SVN server post-commit hook, it compiles every commit that targets ReactOS trunk and Rostests. It outputs Reactos both bootcd and testcd ISOs, stored locally on the machine, which are later on available via dedicated FTP server. TestCD is later on passed to VBox testbot. A build can be triggered manually, via buildbot web interface. SVN credentials are to be passed as username, password, accompanied by revision number that is to be compiled. Please be warned that older revisions, which needed previous ROSBE/GCC version will not be built correctly.
Set up thanks to Amine, Usurp and Timo, this builder is necessary for improving and testing new build implementation, based on CMake. Using cmake branch, it produces both bootcd and testcd, the latter also being passed to VBox testbot. It can be only triggered manually, by passing 'revision' number. This builder 'source' parameter value is: 'x86_CMake'.
A variant of CMake branch builder, which is using MSVC compiler and build tools, instead of GCC. Not producing any ISOs yet, due to ongoing works on porting ReactOS code to MSVC. It can be only triggered manually, by passing 'revision' number. This builder 'source' parameter value is: 'x86_MSVC'.
This branch has new CC kernel module code, commited by Art Yerkes but still not fully functional. Those two builders differ in build setup. Albeit they both share the rewritten CC common code, VBox-NewCC=0 is still using the previous CC code, wheras VBox-NewCC=1 has only new CC code enabled. The reason for splitting the builders is to locate regressions precisely to common/specific CC code and compare performance of both sets. Both builders triggered manually, by passing 'revision' number and will build testcd, passed later on to VBox testbot. Those builder 'source' parameter value is accordingly: 'NewCC0', 'NewCC1'.
This builder is based on Trunk, debug version, but unlike the Trunk_x86_GCCWin builder, its process is designated to testing patches. Given the 'revision' number, as well as custom parameter 'id', with a value of bugzilla attachement id, it will pull the patch attached to this ID, apply it on trunk of given revision, build a testcd and pass it to VBox testbot. This builder 'source' parameter value is: 'x86_Patch'.
This builder is usually triggered by others, if it was mentioned in their description. It will pull a testcd of given 'revision' and from given 'source' builder, then run it by sysreg3 to perform the battery of tests, publishing the results on Testman.. This builder requires three parameters: 'revision' and two custom ones: 'source' and 'id'. When triggering manually, one needs to be sure that testcd of given 'source' and 'revision' (and 'id' if applicable) is present. Parameter 'id' is used only for patchbot builds, but must be passed as empty one in all other cases.
Originated as a separate buildbot project, with its own buildmaster, the initial plan was to make us of this quite powerful machine, to help out testers and developers by having an alternative set of built ReactOS bootcd's. Along with knowledge regarding buildbot itself, adding new features was an adventure of its own. Several builders did not make it to present day, namely x64, ARM and CLang dedicated ones were disabled due to lack of interest. As the setup occured to be reliable and stable, ReactOS team was in need of backup/alternative builder for trunk, if official one was to experience any crash or internal issue of its own.
Testing bot was also sought as necessary alternative, but lack of sysreg support for Windows QEMU, as well as poor performance of this umode based virtualiser, was a main reason for picking VirtualBox instead. First attempts without sysreg, using only crude scripting was limiting the test runs to first crash, hence this direction was abandoned. It was only thanks to Fireball's dedication and work, that allowed VirtualBox sysreg to be created and adopted. Still plagued by some stdio issues with virtual COM, VirtualBox with enchanced support for i7 Core CPU has proved a worthy competition to Linux based KVM. Despite runnining on slower hardware, it performs full test suite in ~40 minutes, over 10 minutes faster than Linux counterpart.
Cmake rewrite opened new areas of interest for buildbot utilisation. CMake branch works were needing the comparison of Winetest results between trunk and branch. Due to design limitations, Testman could only accept data from official buildbot/buildmaster. Unification plans of ReactOS infrastructure was also an argument to merge all builders in one system. It was a perfect opportunity to review and rework scripting, which in turn, modified severly over months of experiments, have grown a think layer of crude and unneeded remnants. Official buildbot also set up a good standard on scripting setup, pushing most of the scripts down to build machines themselves, rather than be stuck in main config file. Apart from clearer design, it also allowed the scripts to be modified at buildbot runtime, whereas even smallest modification to config file had to be applied by rebooting the whole buildbot, the latter being more difficult recently, as all jobs should be finished and buildbot itself should be idle.