User:Zeller: Difference between revisions
Jump to navigation
Jump to search
(VerifiedTag) |
No edit summary |
||
Line 1: | Line 1: | ||
. | == Ship It == | ||
=== Bug 826753 === | |||
* pulse.m.o gives buildbot events | |||
** Look for build.release-*.finished (Found in ['_meta']['routing_key']) | |||
** Use FF candidate buildlogs to help determine the names of the builder I am interested in (ie the first part before "bmNN" is the name of the builder) | |||
*** http://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/31.0b3-candidates/build1/logs/ | |||
** Message format for Buildbot is found on pulse | |||
* Add REST API entry point for updating update.db at /status/<release-name> when POST | |||
* New entry points for shipit | |||
** /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/ | |||
*** GET: Lists release status info in JSON. Analogous to /releases/ | |||
*** 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) | |||
* 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 | |||
* New status table in update.db |
Revision as of 19:49, 2 July 2014
Ship It
Bug 826753
- pulse.m.o gives buildbot events
- Look for build.release-*.finished (Found in ['_meta']['routing_key'])
- Use FF candidate buildlogs to help determine the names of the builder I am interested in (ie the first part before "bmNN" is the name of the builder)
- Message format for Buildbot is found on pulse
- Add REST API entry point for updating update.db at /status/<release-name> when POST
- New entry points for shipit
- /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/
- GET: Lists release status info in JSON. Analogous to /releases/
- 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)
- 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
- New status table in update.db