Changes between Version 9 and Version 10 of Master Slave Protocol
- Timestamp:
- Jul 10, 2005, 11:04:52 PM (19 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Master Slave Protocol
v9 v10 36 36 The server acknowledges that it received the registration with a positive or negative reply. 37 37 38 Next, the server checks whether there are any pending builds for that client . For example, if it is the only client that supports GCC 4.0, and there has been no build of some revision with GCC 4 yet, it will initiate a build on that client. Anyway, the server remembers the client configuration for as long as the connection is open, and may choose to route build requests to that client when repository changes are detected, or a build is triggered otherwise.38 Next, the server checks whether there are any pending builds for that client (see BuildConfigurations). For example, if it is the only client that supports GCC 4.0, and there has been no build of some revision with GCC 4 yet, it will initiate a build on that client. Anyway, the server remembers the client configuration for as long as the connection is open, and may choose to route build requests to that client when repository changes are detected, or a build is triggered otherwise. 39 39 40 40 == Build Initiation == … … 109 109 Content-Type: application/beep+xml 110 110 111 <started />111 <started time="2005-06-29T16:41:22"/> 112 112 END 113 113 }}} 114 115 The {{{time}}} attribute contains the date and time (in ISO 8601 format) at which the build was started. These timestamps must be UTC, and consequently must not contain a timezone offset. 114 116 115 117 The slave then begins executing the steps in the recipe one-by-one (in the order they appear in the file). After each step of the [wiki:BuildRecipes build recipe], the client informs the server, with '''{{{ANS}}}''' messages containing a {{{<step/>}}} element in the payload, about the step it has processed, and what the outcome was (success or failure): … … 119 121 Content-Type: application/beep+xml 120 122 121 <step id="test" description="Run all unit tests" result="success" /> 123 <step id="test" description="Run all unit tests" result="success" 124 time="2005-06-29T16:41:53" duration="7.61"/> 122 125 END 123 126 }}} 127 128 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). 124 129 125 130 In case of an error, the message should include the primary error message in the body of the {{{<step></step>}}} element: … … 129 134 Content-Type: application/beep+xml 130 135 131 <step id="test" description="Run all unit tests" result="success"> 136 <step id="test" description="Run all unit tests" result="failure" 137 time="2005-06-29T16:41:53" duration="7.61"> 132 138 Could not load command "unittest". 133 139 </step> … … 136 142 137 143 '''TODO''': ''Transmission of build log and generated reports to the master'' 144 145 After the slave has processed all of the build steps, it sends an '''{{{ANS}}}''' message containing the element {{{<completed/>}}} in the payload: 146 147 {{{ 148 ANS 1 2 . 0 66 2 149 Content-Type: application/beep+xml 150 151 <completed time="2005-06-29T16:44:02"/> 152 END 153 }}} 138 154 139 155 Furthermore, in case the slave is unexpectedly interrupted while executing a build, it should send an '''{{{ANS}}}''' message containing the element {{{<abort></abort>}}} in the payload:
