Difference between revisions of "Buildslave Warszawa"

From ReactOS Wiki
Jump to: navigation, search
(Hardware)
m (Reverted edits by Blue (talk) to last revision by Haos)
 
(16 intermediate revisions by one other user not shown)
Line 1: Line 1:
The '''[[Buildbot|Buildslave]] Warszawa''' is a multi-purpose buildmachine, focused on aiding ReactOS development. Currently it hosts multiple builders, albeit this is the only one building Trunk in debug mode an attached to a scheduler that is triggered automatically. Unlike Others that need to be triggered by hand.
+
The '''[[Buildbot|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.
  
== Build Machine Hardware ==
+
== Hardware ==
 
  Motherboard: EVGA X58-SLI-LE
 
  Motherboard: EVGA X58-SLI-LE
 
  Processor: Intel i7 920 @ 2.67Ghz (Bloomfield 1366)
 
  Processor: Intel i7 920 @ 2.67Ghz (Bloomfield 1366)
 
  Memory: Triple Channel G-Skill PC3-10700H, 3x 2GB + 3x 1GB
 
  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)
 
  Mass storage: Samsung SpinPoint F3 1TB, 7200rpm, 32MB cache (1x OS, 2 in RAID 0)
 +
  
 
== Builders ==
 
== Builders ==
All built ISO files are available on local FTP server in appropriate directories. BootCDs are stored within root directory, whereas the TestCDs - are in Regtest.
+
All built ISO files are available on local FTP server in the appropriate directories. BootCDs are stored within root directory, whereas TestCDs - in Regtest.
  
 
=== CMake_x86_GCCWin Debug ===
 
=== CMake_x86_GCCWin Debug ===
Setup is thanks to Amine, Usurp and Timo, this CMake-based builder is now a default one on this Buildslave. Triggered by SVN server post-commit hook, it compiles every commit that targets ReactOS trunk and Rostests, producing both bootcd and testcd, the latter being passed to VBox testbot. It can be also triggered manually, by passing 'revision' number.  '''This builder 'source' parameter value is: 'x86_CMake'.'''
+
Set up thanks to Amine, Usurp and Timo, this CMake-based builder is now a default one on this Buildslave. Triggered by SVN server post-commit hook, it compiles every commit that targets ReactOS trunk and Rostests, producing both bootcd and testcd, the latter being passed to VBox testbot. It can be also triggered manually, by passing 'revision' number.  This builder 'source' parameter value is: 'x86_CMake'.
  
 
=== 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: 'x86_MSVC'.'''
+
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'.
  
 
=== NewCC_x86_GCCWin ===
 
=== NewCC_x86_GCCWin ===
This branch has new CC kernel module code, commited by Art Yerkes but still has not achieved full functionality. 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 are triggered manually, by passing 'revision' number the individual that has taken this rout will than build the TestCD, that later on will be passed over to VBox TestBot. '''Those builder 'source' parameter values data accordingly: 'NewCC0', 'NewCC1'.'''
+
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'.
  
 
=== Patch_x86_GCCWin Debug ===
 
=== Patch_x86_GCCWin Debug ===
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 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'.
  
 
=== Windows_AMD64_1 VBox-Test ===
 
=== Windows_AMD64_1 VBox-Test ===
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, will than start running sysreg4 to perform a battery of tests, publishing the results on [http://www.reactos.org/testman/ Testman]... This builder requires three parameters: one 'revision' and two custom ones: 'source' and 'id'. When triggering manually, one needs to be sure that the TestCD of the given 'source' and 'revision' (and 'id' if applicable) is present. Parameter 'id' is used only for PatchBot builds, but must be passed as a empty one in all other cases.
+
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 sysreg4 to perform the battery of tests, publishing the results on [http://www.reactos.org/testman/ 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.
  
 
== History ==
 
== History ==

Latest revision as of 11:59, 13 June 2014

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.

Hardware

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)


Builders

All built ISO files are available on local FTP server in the appropriate directories. BootCDs are stored within root directory, whereas TestCDs - in Regtest.

CMake_x86_GCCWin Debug

Set up thanks to Amine, Usurp and Timo, this CMake-based builder is now a default one on this Buildslave. Triggered by SVN server post-commit hook, it compiles every commit that targets ReactOS trunk and Rostests, producing both bootcd and testcd, the latter being passed to VBox testbot. It can be also triggered manually, by passing 'revision' number. This builder 'source' parameter value is: 'x86_CMake'.

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: 'x86_MSVC'.

NewCC_x86_GCCWin

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'.

Patch_x86_GCCWin Debug

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'.

Windows_AMD64_1 VBox-Test

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 sysreg4 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.

History

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.