Confirmed users
194
edits
Zeller
Joined 28 June 2013
no edit summary
No edit summary |
No edit summary |
||
| Line 18: | Line 18: | ||
* Make /status GET queriable (other than var1 and var2). Other release tables use the column variables ready and complete. | * Make /status GET queriable (other than var1 and var2). Other release tables use the column variables ready and complete. | ||
* Run a JOIN via the name column between release_status and *_releases, and print that JSON info upon /status/<release-name> GET request. | * Run a JOIN via the name column between release_status and *_releases, and print that JSON info upon /status/<release-name> GET request. | ||
* Take progress bars from bootstrap rather than change the entire css | |||
* | * | ||
| Line 31: | Line 32: | ||
* 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 *-release, and check that name is in release_data before adding to release_status... use as switch between creating a new row and updating rows. | * Check to see if name already exists in tables *-release, 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 | |||
=== 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 === | ||
| Line 39: | Line 41: | ||
* If collecting, release_data, then the table will gain ~0.5mb/release, which I estimate makes it ~117Mb/year. | * If collecting, release_data, then the table will gain ~0.5mb/release, which I estimate makes it ~117Mb/year. | ||
* If version = "None", then routing_key doesn't have <u>build</u>.release-* | * If version = "None", then routing_key doesn't have <u>build</u>.release-* | ||
* Some pulse fields are unnecessary, such as 'exchange', and 'serializer' | |||
* Nothing says *.finished | |||
==== 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: | ||
| Line 48: | Line 52: | ||
* 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) | ||
* | * Does only build.release-* need to be caught, or also unittest.release-*, talos.release-*, etc? | ||
==== To Do ==== | ==== To Do ==== | ||
* 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 | * 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 | ||