User:Zeller: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 14: | Line 14: | ||
==== Notes ==== | ==== Notes ==== | ||
==== Questions ==== | ==== Questions ==== | ||
* How exactly should I divide the release pulse messages into the 6 statuses: Tagging completed, All builds/repacks completed, Updates on betatest, Ready for releasetest, Ready for release and Postrelease. | |||
* | |||
==== To Do ==== | ==== To Do ==== | ||
* Add REST API entry point for updating update.db at /status/<release-name> when POST | * Add REST API entry point for updating update.db at /status/<release-name> when POST | ||
| Line 23: | Line 25: | ||
** Use [http://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/31.0b3-candidates/build1/logs/ 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) | ** Use [http://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/31.0b3-candidates/build1/logs/ 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) | ||
==== Questions ==== | ==== Questions ==== | ||
* What do do with release messages that don't fit the expected: | |||
** Have something other than build.release-* (ie unittest.release-*, talos.release-*, etc) | |||
** Have version, build_number = None | |||
** Have a product other than "firefox" when supposedly it's a firefox build (ie "mobile" or "xulrunner" | |||
==== 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 | ||
| Line 29: | Line 35: | ||
==== Notes ==== | ==== Notes ==== | ||
==== Questions ==== | ==== Questions ==== | ||
* Should we have 2 tables (release_status and release_data), or just 1 (release_status)? | |||
* Is release_status schema adequete? | |||
* | |||
==== To Do ==== | ==== To Do ==== | ||
* New status table in update.db | * New status table in update.db | ||
Revision as of 22:13, 2 July 2014
Ship It
Bug 826753 - release automation should update ship it at certain points
Notes
Questions
To Do
- /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)
Bug 1032985 - Add REST API entry point to shipit that allows shipit-agent to enter release data into shipit database
Notes
Questions
- How exactly should I divide the release pulse messages into the 6 statuses: Tagging completed, All builds/repacks completed, Updates on betatest, Ready for releasetest, Ready for release and Postrelease.
To Do
- Add REST API entry point for updating update.db at /status/<release-name> when POST
Notes
- 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)
Questions
- What do do with release messages that don't fit the expected:
- Have something other than build.release-* (ie unittest.release-*, talos.release-*, etc)
- Have version, build_number = None
- Have a product other than "firefox" when supposedly it's a firefox build (ie "mobile" or "xulrunner"
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
Bug 1032975 - Add new table(s) to shipit database
Notes
Questions
- Should we have 2 tables (release_status and release_data), or just 1 (release_status)?
- Is release_status schema adequete?
To Do
- New status table in update.db