Changes between Version 14 and Version 15 of Master Slave Protocol
- Timestamp:
- Nov 10, 2005, 5:07:59 PM (19 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Master Slave Protocol
v14 v15 49 49 When the build server detects that builds are necessary for some revision of the project, it queries its database of available slaves and chooses a set of slaves with non-overlapping configurations. For example, if there are 10 clients available that could execute the build of a Java project on Windows 2000 with JDK 1.4, it will only select one of those to actually perform the build. 50 50 51 A build request consists of the [wiki:BuildRecipes build recipe], andcontains the instructions that the slave must follow to execute the build:51 A build request consists of the name of the project and the [wiki:BuildRecipes build recipe] that contains the instructions that the slave must follow to execute the build: 52 52 {{{ 53 53 #!xml … … 55 55 Content-Type: application/beep+xml 56 56 57 <build xmlns:python="http://bitten.cmlenz.net/tools/python">57 <build project="example" xmlns:python="http://bitten.cmlenz.net/tools/python"> 58 58 <step id="compile"> 59 59 <python:distutils command="build"/> … … 87 87 If the client accepts a build request by sending a positive reply, the server will transmit a tarball of the code base that is to be built. The client does not need to know which exact revision (or branch) of the project it is building, nor does it need to perform a checkout itself. 88 88 89 A client accepts a build request by responding with a '''`RPY`''' message containing a `<proceed ></proceed>` element in the payload. The reply must contain a list of archive formats that the slave supports for transmission of the code. For example:89 A client accepts a build request by responding with a '''`RPY`''' message containing a `<proceed/>` element in the payload. For example: 90 90 91 91 {{{ … … 94 94 Content-Type: application/beep+xml 95 95 96 <proceed> 97 <accept type="application/tar" encoding="bzip2" /> 98 <accept type="application/tar" encoding="gzip" /> 99 </proceed> 96 <proceed/> 100 97 END 101 98 }}} 102 103 In this message, the client indicates that it will accept `tar` archives with `bzip2` or `gzip` compression (preferring the former). Another client might specify that it supported only ZIP archives.104 99 105 100 After having received such a reply, the master can proceed by transmitting a snapshot of the code base to the slave: 106 101 {{{ 107 102 MSG 1 2 * 0 3421 108 Content-Type: application/tar 109 Content-Disposition: myproject-r456.tar 110 Content-Transfer-Encoding: gzip 103 Content-Type: application/zip 104 Content-Disposition: myproject-r456.zip 111 105 112 106 ... … … 121 115 122 116 <error code="550"> 123 Invalid tar.gzarchive117 Invalid ZIP archive 124 118 </error> 125 119 END … … 157 151 }}} 158 152 159 '''TODO''': report and log elements 153 The `time` attribute specifies the date and time at which processing of this step was started. The `duration` attribute contains the number of seconds that it took to complete the step (this may include fractions). 160 154 161 The `time` attribute specifies the date and time at which processing of this step was started. The `duration` attribute contains the number of seconds that it took to complete the step (this may include fractions). 155 The `<step></step>` element may contain one or more child elements: 156 * `<error></error>` elements indicate errors in the execution of the step, 157 * `<log></log>` elements contain the build log output, and 158 * `<report></report>` elements contain generated [wiki:DataStorage report data]. 162 159 163 160 After the slave has processed all of the build steps, it sends a final '''`ANS`''' message containing the element `<completed/>` in the payload:
