tl;dr I personally think we should consider bootspeed, power testing, smem, etc as part of the CI Airline uce-1 and uce-2 milestones.
For those of you not subscribed to wiki changes under UbuntuEngineering/CI/*, I've finally dumped the whiteboard notes from the sprint: https://wiki.canonical.com/UbuntuEngineering/CI/Jenkins As we look to the architecture design of the Airline beyond uce-0 (what we need to replace CI Train with it), we should consider what of this functionality can become part of the train. On one hand, I'm a firm believer of the Unix philosophy of "do one thing and do it well." I think it goes without saying that I don't like big, monolithic structures. My original thoughts were that we should have isolated test systems, each running their own Jenkins in Prodstack. I'm still all for keeping Jenkins usage as small as possible, but I'm starting to see the point Alex has when he suggests that we should be incorporating all these types of tests into the airline. When they're isolated functions we cannot take advantage of them on branch and source testing, outside of the daily image testing. Shouldn't we let the developer know if their branch is going to regress bootspeed, or increase power usage? I don't want us to invest coding time in solving that straight away. I think we should still do a prodstack migration of our Jenkins deployments that are not so immediately replaced by the Train and Airline. However, I think it's worth diagraming out what this will look like as part of uce-1 (October) and uce-2 (January). -- Mailing list: https://launchpad.net/~canonical-ci-engineering Post to : [email protected] Unsubscribe : https://launchpad.net/~canonical-ci-engineering More help : https://help.launchpad.net/ListHelp
