internals:buildbot
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revisionLast revisionBoth sides next revision | ||
internals:buildbot [2009/09/18 22:58] – Build farm and debugging on "foreign platforms" page bjori | internals:buildbot [2011/06/05 00:24] – http -> https scottmac | ||
---|---|---|---|
Line 29: | Line 29: | ||
To gain access to these boxes, mail systems@. | To gain access to these boxes, mail systems@. | ||
+ | ===== Proposed Implementation ===== | ||
+ | After this continuous integration server is completed and finalized, it will be replicated | ||
+ | across the other UNIX servers in a slave-master set up. | ||
+ | |||
+ | For now, each slave will be doing pretty much what the master is doing (testing php 5.2, 5.3 and 6.0) | ||
+ | |||
+ | However, the results will only be accessible and stored on the master server. | ||
+ | |||
+ | Here is the rough draft for the implementation details: | ||
+ | |||
+ | Please contact me at iekpo@php.net if you have any questions, comments or recommendations. | ||
+ | |||
+ | ==== 0. Target Subversion URLs ==== | ||
+ | |||
+ | The priority as stated by Hannes Magnusson, is to set it up for | ||
+ | PHP 5.3 first then PHP 5.2 and 6.0+ | ||
+ | |||
+ | So the build bot will only be monitoring commits to the following subversion URLS : | ||
+ | |||
+ | * PHP 5.3: https:// | ||
+ | * PHP 5.2: https:// | ||
+ | * PHP 6: | ||
+ | |||
+ | A separate build daemon will be set up for each branch on each UNIX server. | ||
+ | |||
+ | ====1. Notification of Build System ==== | ||
+ | |||
+ | A post commit hook will notify the build system that a commit has occurred (I will need the assistance of systems guys set up this post-commit hook). | ||
+ | |||
+ | A simple web service will be set up at the master to receive these notifications. | ||
+ | |||
+ | The revision number will be entered into a queue and then a queue processing | ||
+ | system will take it from there. | ||
+ | |||
+ | The notification will be sent to the master and the other slaves will | ||
+ | be notified after that. | ||
+ | |||
+ | I am planning for the master to be the Debian server and the other servers | ||
+ | will be the slaves. | ||
+ | |||
+ | |||
+ | ==== 2. Processing items in the queue ==== | ||
+ | |||
+ | The build will occur in very distinct phases/ | ||
+ | |||
+ | Each stage/state will be fine-tuned or broken down if needed in the future. | ||
+ | |||
+ | We should be able to find out what state a particular job is at any give instant. | ||
+ | |||
+ | Here are the states : | ||
+ | |||
+ | * 2A : The source code will be checked out of SVN. | ||
+ | * 2B : Then the buildconf command will be run. | ||
+ | * 2C : Then the configure script will be run will all the extensions enabled. | ||
+ | * 2D : Then make | ||
+ | * 2E : Then make install | ||
+ | |||
+ | If any of the above steps fail, this particular job is put on HOLD and an email notification will be sent out. | ||
+ | |||
+ | * 2F : Then make test (or any other simpler alternative) | ||
+ | |||
+ | * 2G: The results will then be agregated an analyzed. This will be explained in 4 below | ||
+ | |||
+ | However, we have to take care of the following cases/ | ||
+ | |||
+ | * 1. Removal of phpt scripts (a phpt script that was in the previous revision no longer exists) | ||
+ | * 2. Addition of new phpt scripts (a phpt script that never existed is now introduced) | ||
+ | |||
+ | |||
+ | ==== 3. Handling Errors and Build-Failures ==== | ||
+ | |||
+ | Whenever a particular build fails (steps 2A-E), human intervention may | ||
+ | be needed because the reason could be a missing dependency such as libraries, tools etc. | ||
+ | |||
+ | As for steps 2G, someone will have to fix the source code to make it PASS the test. | ||
+ | |||
+ | If the problem is not in the source code, then the phpt script may have to be adjusted to make it pass the test. | ||
+ | |||
+ | |||
+ | ==== 4. Intepretation of Build results ==== | ||
+ | |||
+ | 2G1 : Existing phpt files | ||
+ | |||
+ | * If the result changes from PASS to FAIL, a FAILURE notice will be sent out (RED) | ||
+ | * If the result changes from FAIL to PASS, a RESTORED notice will be sent out (GREEN) | ||
+ | * If the result remains at PASS, no notice will be sent out. | ||
+ | * If the result remains at FAIL, no notice will be sent out. | ||
+ | |||
+ | 2G2 : Removed phpt files. | ||
+ | A REMOVED notice will be sent out (ORANGE) | ||
+ | |||
+ | 2G3 : Newly introduced phpt files. | ||
+ | * If the result is FAIL, a FAILURE notice will be sent out (RED) | ||
+ | * If the result is PASS, a PASS notice will be sent out (GREEN) | ||
+ | |||
+ | ==== 5. Managing Results Data ==== | ||
+ | |||
+ | The results will be stored in a MySQL database that will be archived from time to time. | ||
+ | |||
+ | There will be a web interface to view the results of each test for each server and SVN URL | ||
+ | |||
+ | |||
+ | ==== References : ==== | ||
+ | |||
+ | http:// | ||
+ | |||
+ | http:// |
internals/buildbot.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1