Confirmed users
2,456
edits
User:Catlee/BuildAPI: Difference between revisions
→List of request methods, urls, and parameters
| (2 intermediate revisions by the same user not shown) | |||
| Line 21: | Line 21: | ||
GET /builds/{branch}/builders/{buildername} -> list of recent builds, including completed, running, and pending for this builder name | GET /builds/{branch}/builders/{buildername} -> list of recent builds, including completed, running, and pending for this builder name | ||
GET /builds/ | GET /builds/jobs/{job_id} -> status on job request (e.g. cancel build, etc.) | ||
PUT /builds/{branch}/request/{requestid} -> update this build | PUT /builds/{branch}/request/{requestid} -> update this build | ||
| Line 38: | Line 38: | ||
POST /builds/{branch}/rev/{revision} -> create a new build with this revision | POST /builds/{branch}/rev/{revision} -> create a new build with this revision | ||
* properties (optional, extra properties for this build) | * properties (optional, extra properties for this build) | ||
| Line 74: | Line 73: | ||
= Implementation Notes = | = Implementation Notes = | ||
(source at http://hg.mozilla.org/users/catlee_mozilla.com/buildapi/file/493320c66935/RESTAPI_NOTES.txt) | |||
== Routing == | |||
Or, how do URLs get turned into method calls? | |||
Look in buildapi/config/routing.py. All the /builds/ urls are to support | |||
the REST API. | |||
URLs get matched to an appropriate route based on these rules, and then | |||
methods in buildapi/controllers/builds.py are called. | |||
== GETting data == | |||
Most GET queries do a few simple operations: | |||
1) validate parameters | |||
2) make db calls with methods in buildapi/model/builds | |||
3) return results | |||
Results are formatted according to the 'format' query parameter | |||
("?format=html" or "?format=json"). If 'format' is not set, and the | |||
'Accept' header of the request is set to 'application/json', the format | |||
will be set to json. Otherwise the format will be html. These rules are | |||
implemented in buildapi.lib.base.BaseController._get_method_args. | |||
== Job Requests == | |||
PUT, POST, and DELETE requests (which can be faked by setting a '_method_' | |||
field to 'PUT' or 'DELETE' in a regular POST request if your client doesn't | |||
support PUT/DELETE easiliy...a nice feature of Routes!) represent requests | |||
to change buildbot state. These are called "Job Requests". | |||
Job requests follow a simple flow: | |||
1) log request in jobrequests table of buildapi database. Return | |||
jobrequest id to client. The client can query the status of this job via | |||
the /builds/job_status/{job_id} method. | |||
2) send message to message broker on the 'requests' routing key with | |||
details of job request. | |||
3) an external agent (such as buildapi/scripts/buildapi-agent.py) receives | |||
the message, acts on it, and then sends a message on the 'finished' routing | |||
key to indicate the job was completed. | |||
TODO: agent should have a way of attaching failure information | |||
4) a thread in the web app is waiting for messages on the 'finished' | |||
routing key. It will update the jobrequests table when jobs are completed. | |||