Let's use this ticket for tracking this work.
Thanks to Mark for offering up the old API boxes for this; it'll be really useful.
Can someone from Ops let me/this ticket know what the next steps are here?
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | hashar | T60772 common gating job for mediawiki core and extensions | |||
| Resolved | hashar | T69216 Have unit tests of all wmf deployed extensions pass when installed together, in both PHP-Zend and HHVM (tracking) | |||
| Invalid | Ryasmeen | T90647 Create Jenkins builds for Editing across repositories (MobileFrontend, VisualEditor etc) | |||
| Declined | None | T50407 Jenkins: Setup Vagrant for some jobs (tracking) | |||
| Declined | None | T45266 Write and implement tests for Wikimedia's Apache configuration (redirects.conf, etc.) | |||
| Resolved | hashar | T47499 [EPIC] Run CI jobs in disposable VMs | |||
| Declined | hashar | T84940 Acquire old production API servers for use in CI |
Event Timeline
Comment Actions
+Coren I talked with him about CI labs during the summer.
That is following the meeting we had for the RFC "Extensions continuous integration" (T1350). With more and more tests being run we need more CPU processing, and the more we have the more tests we can add to our repositories.
For the context, I want to move most tests to run on labs instances since it is easy to scale. We will eventually spawn a new instance per job build and destroy it after.
Possibly, we could add a share of the old apps server to the wmflabs infrastructure and dedicate them to the CI project. Apparently OpenStack has support for that. Then we can use the OpenStack API to maintain a pool of labs instance on that hardware to save up the initialization time and then have them consumed by Jenkins jobs.
Comment Actions
Filled T84989: Support dedicating a specific virt node to a specific nova project to see how we could dedicate that material to CI.
Comment Actions
Yeah. CI isn't currently in need of more bare-metal nodes as Jenkins slaves (like gallium and lanthanum are at the moment). These resources would be better spent on our cluster of labs instances.
Comment Actions
We might have a use for them to set some CI supporting servers straight inside the labs infrastructure. That would host the Zuul mergers which provides the patch sets and mostprobably nodepool which needs to interact with the OpenStack API on some virt* machine.
That would mean most would be moved out of production as labs bare metal servers.
Will make a proposal along that way with T86171: Design the Jenkins isolation architecture
Comment Actions
We are using labs infrastructure for now. There is no plan to reuse the old mw apps server.