canonical-ci-engineering team mailing list archive

[Evan Dandrea <evan.dandrea@xxxxxxxxxxxxx>]

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).