Confirmed users
194
edits
Zeller
Joined 28 June 2013
no edit summary
No edit summary |
No edit summary |
||
| Line 4: | Line 4: | ||
* /status - Lists all available releases, that have status data, in JSON format and can be queried with parameters (ie /status?var1=1&var2=10). Analogous to /releases | * /status - Lists all available releases, that have status data, in JSON format and can be queried with parameters (ie /status?var1=1&var2=10). Analogous to /releases | ||
* /status.html – Pretty GUI view of the info shown in /status. Analogous to /releases.html | * /status.html – Pretty GUI view of the info shown in /status. Analogous to /releases.html | ||
* /status/ | * /status/<release-name> | ||
** GET: Lists release status info in JSON. Analogous to /releases/ | ** GET: Lists release status info in JSON. Analogous to /releases/<release-name> | ||
** POST: covered in Bug 1032985 | ** POST: covered in Bug 1032985 | ||
* /status/.html – Pretty GUI view of the info shown in /status/ GET, possibly including a visual timeline of the 6 steps: Tagging completed, All builds/repacks completed, Updates on betatest, Ready for releasetest, Ready for release and Postrelease. (status steps taken from Bug 826753 comment 0) | * /status/.html – Pretty GUI view of the info shown in /status/ GET, possibly including a visual timeline of the 6 steps: Tagging completed, All builds/repacks completed, Updates on betatest, Ready for releasetest, Ready for release and Postrelease. (status steps taken from Bug 826753 comment 0) | ||
==== Questions ==== | ==== Questions ==== | ||
* Why does / | * Why does /release 404? | ||
* Should /statuses be available through a 3rd tab (ie Reviewed/Completed/Statuses), or through a new "view statuses" link? | * Should /statuses be available through a 3rd tab (ie Reviewed/Completed/Statuses), or through a new "view statuses" link? | ||
* Does a ViewStatuses() need to be added to kickoff.js? In addition to the ViewReleases() function? | * Does a ViewStatuses() need to be added to kickoff.js? In addition to the ViewReleases() function? | ||
| Line 22: | Line 22: | ||
=== Bug 1032985 - Add REST API entry point to shipit that allows shipit-agent to enter release data into shipit database === | === Bug 1032985 - Add REST API entry point to shipit that allows shipit-agent to enter release data into shipit database === | ||
https://bugzilla.mozilla.org/show_bug.cgi?id=1032985#c2 | |||
Add REST API entry point for updating update.db at /status/<release-name> when POST | |||
==== Notes ==== | ==== Notes ==== | ||
* Use name field in release_status as an unofficial foreign key to the 3 *_releases tables (Can't use JOIN for 3 primary keys (all name) in the *_releases tables) | * Use name field in release_status as an unofficial foreign key to the 3 *_releases tables (Can't use JOIN for 3 primary keys (all name) in the *_releases tables) | ||
| Line 29: | Line 32: | ||
* | * | ||
==== To Do ==== | ==== To Do ==== | ||
* Have StatusAPI update the database tables *-release, and check that name is in release_data | * Have StatusAPI update the database tables *-release, and check that name is in release_data | ||
* Check to see if name already exists in tables *- | * Check to see if name already exists in tables *-releases, and check that name is in release_data before adding to release_status... use as switch between creating a new row and updating rows. | ||
* DATETIME stamps need to not have T or +01:00 | * DATETIME stamps need to not have T or +01:00 | ||
* Sort data into the 6 statuses | |||
* | |||
=== Bug 1032978 - Add a standalone process that listens to pulse for release related buildbot messages === | === Bug 1032978 - Add a standalone process that listens to pulse for release related buildbot messages === | ||
Long-running standalone script (shipit-agent.py) that listens to pulse and uses / status/<release-name> with POST to update update.db for <release-name> status | |||
==== Notes ==== | ==== Notes ==== | ||
* pulse.m.o gives buildbot events | * pulse.m.o gives buildbot events | ||
| Line 43: | Line 48: | ||
* Some pulse fields are unnecessary, such as 'exchange', and 'serializer' | * Some pulse fields are unnecessary, such as 'exchange', and 'serializer' | ||
* Nothing says *.finished | * Nothing says *.finished | ||
* Ignore the following messages: | |||
** Any routing_key that doesn't match build.release-* (including unittest.release-*, talos.release-*, etc... they are tests we don't usually look at. | |||
** Any version or build_number that is None... there was a bug for that, they are test related | |||
** Any xulrunner jobs, they are implicitly run by Firefox | |||
* [Examples https://bugzilla.mozilla.org/show_bug.cgi?id=1032985#c2] given by rail on how to sort pulse messages into the 6 statuses | |||
==== Questions ==== | ==== Questions ==== | ||
* What do do with release messages that don't fit the expected: | * What do do with release messages that don't fit the expected: | ||
** Have a product other than "firefox" when supposedly it's a firefox build (ie "mobile" or "xulrunner" | ** Have a product other than "firefox" when supposedly it's a firefox build (ie "mobile" or "xulrunner" | ||
* Did I scrap all of Firefox-31.0b5-build1 or am I missing something? | * Did I scrap all of Firefox-31.0b5-build1 or am I missing something? | ||
* Should I look at routing_key, or key, or? | * Should I look at routing_key, or key, or? | ||
* Do we want to keep all buildbot release pulse data, to be able to use it later to deduce new things, or forgoe all that entirely? (feature creep) | * Do we want to keep all buildbot release pulse data, to be able to use it later to deduce new things, or forgoe all that entirely? (feature creep) | ||
* | * Should protocol be configurable via puppet or with command line option? | ||
* Is it possible to use the topic option with pulse to listen to only build.release-* messages? | |||
==== To Do ==== | ==== To Do ==== | ||
* | * Give rail an example of the product "mobile" showing up when I expect "firefox" | ||
* Run with supervisord if supposed to be run in the foreground | |||
* Read credentials from a file deploted by puppet, rather than relying on .netrc for username and password | |||
* Make protocol configurable via puppet or with command line option | |||
* Use selfserve-agent.py as the template for this | |||
* | |||
=== Bug 1032975 - Add new table(s) to shipit database === | === Bug 1032975 - Add new table(s) to shipit database === | ||
New table(s) in update.db | |||
==== Notes ==== | ==== Notes ==== | ||
==== Questions ==== | ==== Questions ==== | ||
| Line 63: | Line 77: | ||
* | * | ||
==== To Do ==== | ==== To Do ==== | ||
* | * Give rail the estimate for how much data will be added to the release_data table | ||
* Show sheeri the schema for help in optimizing columns, and to get other feedback once ready | |||