User:Catlee/SchedulerDB: Difference between revisions

No edit summary
 
(23 intermediate revisions by 2 users not shown)
Line 11: Line 11:
|-
|-
| Builds should happen after a checkin
| Builds should happen after a checkin
|
| {{done|}}
|
|
|-
|-
| Nightly en-US build should trigger repacks after build is done
| Nightly en-US build should trigger repacks after build is done
|
| {{done|}}
|
|
|-
|-
| Change to locale repo should trigger a single repack
| Change to locale repo should trigger a single repack
|
| {{done|}}
|
|
|-
|-
| Nightly builds should get fired
| Nightly builds should get fired
|
| {{done|}}
|
|
|-
|-
Line 31: Line 31:
|-
|-
| Queued changes / builds are restored after restarting buildbot master
| Queued changes / builds are restored after restarting buildbot master
| {{done|}}
|
|
|-
| Multiple masters can share the same database for the same builders
| {{done|}}
|
|
|-
|-
| Multiple masters can share the same database for the same builders
| Test that sendchanges between masters is working
| {{done|}}
|
|
|-
| Test that nomerge changes aren't getting merged (e.g. talos runs, unittest runs, l10n repacks)
| {{done|}}
|
|
|-
|-
| Test that sendchanges between masters is working
| Test that builds that get abandoned because of a failed master get re-run
| {{done|}}
|
|
|-
| Test that new buildbot code can work with old master
|
|
|
|
|-
|-
| Test that nomerge changes aren't getting merged (e.g. talos runs, unittest runs, l10n repacks)
| Test that builds,repacks produced are valid
|
|
|
|-
| Test mobile master code
|
|
|
|
Line 51: Line 65:
= Timeline =
= Timeline =


* Week of March 1st
== Build ==
** deploy new python, twisted toolchain on staging master, talos staging master
* March 1st-April 6th
** deploy new python, twisted toolchain on staging master
** deploy current buildbot tip on staging master and slaves, start testing current patches (see test cases to exercise above)
** deploy current buildbot tip on staging master and slaves, start testing current patches (see test cases to exercise above)


* Week of March 8th
* ??? Buildbot 0.8.0 release or choosing some stable revision prior to release
** Python / twisted upgrade on production master (going to python 2.6.4, twisted 9.0.0 or 9.0.1).  ''can be deferred''
** not all issues blocking 0.8.0 release affect us
** deploy current buildbot tip on talos staging master and slaves, start testing current patches
 
* April 5-7 Deploy buildbot 0.8.0 on staging build/unittest master


* TBD Buildbot 0.8.0 release or backporting of db features to 0.7.12+
* April 12 Deploy buildbot, python, twisted onto production build masters and slaves
** pm01, pm03 to start.  pm01 will be the 'scheduler' master, and possibly handle one builder pod as well.
** One low-traffic branch to start.  Places?
** Will need to steal slaves from other masters.  Could impact wait times.
** Slave upgrade isn't strictly necessary to do, but feels right thing to do.
*** has the potential to break builds (if e.g. part of build doesn't work with python 2.6). If needed, we could isolate build tools from system tools.


* 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.
== Talos ==
* TBD
** deploy new python, twisted toolchain on talos staging master
** deploy current buildbot tip on talos staging master and slaves, start testing current patches
** blocked on access to staging env?


* TBD Deployment of buildbot onto production build masters and slaves
* TBD Deploy buildbot 0.8.0 on staging talos master


* TBD Deployment of buildbot onto production talos masters and slaves
* TBD Deploy buildbot onto production talos masters and slaves
** Python / twisted upgrade on production talos masters (going to python 2.6.4, twisted 9.0.0 or 9.0.1).


= Notes =
= Notes =
Line 72: Line 98:


* 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.
* 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.
* Release configs can be handled later as well.  We're going to be rolling out onto a few branches at first.  Until all the current masters are moved over, releases can be done on the old masters.
Confirmed users
2,456

edits