User:Catlee/SchedulerDB: Difference between revisions

 
(16 intermediate revisions by the same user 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|}}
|
|-
| 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 builds that get abandoned because of a failed master get re-run
| {{done|}}
|
|
|-
|-
| Multiple masters can share the same database for the same builders
| Test that new buildbot code can work with old master
|
|
|
|
|-
|-
| Test that sendchanges between masters is working
| Test that builds,repacks produced are valid
|
|
|
|
|-
|-
| Test that nomerge changes aren't getting merged (e.g. talos runs, unittest runs, l10n repacks)
| Test mobile master code
|
|
|
|
Line 49: Line 65:
= Timeline =
= Timeline =


* March 1st-12th
== Build ==
* March 1st-April 6th
** deploy new python, twisted toolchain on staging master
** 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)


* March 15th-26th
* ??? Buildbot 0.8.0 release or choosing some stable revision prior to release
** deploy new python, twisted toolchain on talos staging master
** 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 1 Buildbot 0.8.0 release or backporting of db features to 0.7.12+
* April 5-7 Deploy buildbot 0.8.0 on staging build/unittest master
** would only backport to 0.7.12 if 0.8.0 takes too long to release


* April 1-5 Deploy buildbot 0.8.0 on staging build/unittest master
* 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.


* April 1-5 Deploy buildbot 0.8.0 on staging talos master
== 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?


* April 6 Deploy buildbot, python, twisted onto production build masters and slaves
* TBD Deploy buildbot 0.8.0 on staging talos master
** 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.


* April 13 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).
** Python / twisted upgrade on production talos masters (going to python 2.6.4, twisted 9.0.0 or 9.0.1).


Line 76: 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