User:Zeller

Ship It

Bug 826753 - release automation should update ship it at certain points

Notes

• /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)

Questions

• Why does /releases/ 404? (REMOVE /)
• 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?

To Do

• Fix line 331 in model.py to sort the product properly
• When RelMan hits 'go', add proper row to database
• Make system diagram for interactions in shipit additions
• 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.

Bug 1032985 - Add REST API entry point to shipit that allows shipit-agent to enter release data into shipit database

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)

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
• 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.

Bug 1032978 - Add a standalone process that listens to pulse for release related buildbot messages

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)
• 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 build.release-*

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"
• What do I do with xulrunner.* rows?
• Did I scrap all of Firefox-31.0b5-build1 or am I missing something?
• 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)

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

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