User:Catlee/SchedulerDB: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 39: Line 39:
|-
|-
| Test that sendchanges between masters is working
| Test that sendchanges between masters is working
|
|
|
|
|
|-
|-
| Test that nomerge changes aren't getting merged (e.g. talos runs, unittest runs, l10n repacks)
| Test that nomerge changes aren't getting merged (e.g. talos runs, unittest runs, l10n repacks)
|
|
|
|
|

Revision as of 22:05, 26 February 2010

Road to great justice for schedulerdb!

Test cases

Description Manually tested? Automated test in place? Notes
Builds should happen after a checkin
Nightly en-US build should trigger repacks after build is done
Change to locale repo should trigger a single repack
Nightly builds should get fired
Release l10n repacks should get fired
Queued changes / builds are restored after restarting buildbot master
Multiple masters can share the same database for the same builders
Test that sendchanges between masters is working
Test that nomerge changes aren't getting merged (e.g. talos runs, unittest runs, l10n repacks)

Timeline

  • Week of March 1st
    • deploy new python, twisted toolchain on staging master, talos staging master
    • deploy current buildbot tip on staging master and slaves, start testing current patches (see test cases to exercise above)
  • Week of March 8th
    • Python / twisted upgrade on production master (going to python 2.6.4, twisted 9.0.0 or 9.0.1). can be deferred
    • deploy current buildbot tip on talos staging master and slaves, start testing current patches
  • TBD Buildbot 0.8.0 release or backporting of db features to 0.7.12+
  • TBD Python / twisted upgrade on slaves? Not as necessary to do...has the potential to break builds (if e.g. part of build doesn't work with python 2.6), but could isolate build tools from system tools.
  • TBD Deployment of buildbot onto production build masters and slaves
  • TBD Deployment of buildbot onto production talos masters and slaves

Notes

  • The current try server code doesn't need to be touched, since all that code is going to be integrated into the main configs, which should "just work".
  • Talos can be handled later if required. Its scheduling is pretty straightforward. It's also a good piece to test in parallel with the build bits.