~barry/bileto/lp1538716

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
Overview of Bileto's Public API, V1
===================================


GET /v1/tickets

This is the main endpoint, which will return a json blob that looks like this:

{
  "requests": [
    {
      "comments": [
        {
          "author": "timo-jyrinki",
          "date": "2015-07-06T06:30:12.899689",
          "id": 3,
          "request_id": 6,
          "text": "I approve this!"
        },
        {
          "author": "robru",
          "date": "2015-07-10T21:06:01.354658",
          "id": 6,
          "request_id": 6,
          "text": "thanks Timo!"
        }
      ],
      "date": "2015-07-01T13:11:58.852196",
      "description": "browser desktop tabs prototype",
      "dest": "",
      "distribution": "ubuntu",
      "download_links": "",
      "jenkins": "http://ci-train.staging.ubuntu.com",
      "landers": "oSoMoN",
      "merge_proposals": "https://code.launchpad.net/~osomon/webbrowser-app/desktop-tabs-prototype/+merge/262358",
      "published_versions": "",
      "qa_signoff": "Ready for QA",
      "request_id": 6,
      "search": "6\nbrowser desktop tabs prototype\n\nhttps://code.launchpad.net/~osomon/webbrowser-app/desktop-tabs-prototype/+merge/262358\noSoMoN\nPackages built\nubuntu/landing-000\n\nubuntu\ndual\n\nReady for QA",
      "series": "dual",
      "siloname": "ubuntu/landing-000",
      "sources": "",
      "status": "Packages built",
      "sync_request": "",
      "test_plan": "",
    }
  ]
}

By default it will not return any requests in state 'Landed' or 'Abandoned'. If
you want to see those, you can query them like so:

    /v1/tickets?status=Landed
    /v1/tickets?status=Abandoned

If any HTTP GET parameters are given (that is /v1/tickets?foo=bar), this will
be used to query the records based on the named fields. So for example if you
just want to see what's ready for QA, you can do this:

    /v1/tickets?qa_signoff=Ready

Or for a specific lander:

    /v1/tickets?landers=robru

The db also has a 'search' field which is a concatenation of most other fields,
effectively allowing one search to search across many fields:

    /v1/tickets?search=foobar

It is possible to specify multiple fields if you want to get specific. Also,
if you want to remove Landed and Abandoned tickets from your search results,
you can add this token to the URL:

    /v1/tickets?active_only&landers=robru


POST /v1/tickets?token=

POSTing to /v1/tickets requires either the API token, which only Jenkins knows,
or the session cookie from your browser (which is how the web UI works).
POSTing by third-party scripts is possible with your session cookie but
unsupported.

The json format to submit here must match the request objects returned from
GETting /v1/tickets, however a few fields such as "date" and "comments" will
be ignored.

Note that all POSTs containing 'request_id' (that is, all POSTs that update a
ticket rather than creating a new one) will also automatically create a comment
indicating what value changed. You should always include the 'author' field to
indicate what user made the change, or your bot's name, as appropriate.


GET /v1/ticket/[REQUEST_ID]

If you know the id of the ticket you want to access, you can fetch it
directly from this endpoint. The returned json blob will have the same
structure as /v1/tickets, eg, {"requests": [{...}]}


GET /v1/user/[LANDER_NAME]

If you know the name of the lander you want to search, you can fetch it
directly from this endpoint. The returned json blob will have the same
structure as /v1/tickets, eg, {"requests": [{...}]}. Technically this is a
substring search, so eg accessing /v1/user/bob will return requests where the
landers field contains 'bobbert'. This will not return requests in state Landed
or Abandoned.


GET /v1/silo/[SILONAME]

Substring search for silonames, excluding Landed and Abandoned, returns same
format as all other endpoints. Supports both /v1/silo/001 and
/v1/silo/ubuntu/landing-001.


GET /v1/publishable

This endpoint will return only requests that require trainguard action, that
is, silos in state 'Packages built' with qa_signoff of either 'QA Granted' or
'Publish without QA'. Trainguards can then publish these silos easily without
having to hunt throught he larger list on the main endpoint. As usual, the
returned JSON follows the same format as /v1/tickets


GET /v1/failures

This endpoint will return only requests that have a status containing either
"can't", "failed", or "error". As usual, the returned JSON follows the same
format as /v1/tickets


GET /v1/metadata

This is a simple endpoint which returns some details about Bileto itself, such
as the documentation for each db field, and values for various drop-down lists.
This is mostly a bespoke endpoint used to communicate from the backend to
the frontend and shouldn't concern third-party scripts much at all.


POST /v1/comment

Can be POSTed to by either logged-in users or bots with API_TOKEN. You must
include the request_id you are commenting on as well as comment text, eg:

{"request_id": 6, "text": "This request is broken, please fix it."}