Re: Future directions for Continuous

[Rob Taylor <rob taylor codethink co uk>]

On 22/10/14 17:00, Colin Walters wrote:
> Continuous emerged from a couple of different backgrounds; my
> frustration with the packaging model, the need for end-to-end testing,
> etc.  However, while it's something one could imagine turning into a
> product if it was professionally maintained (with security updates),
> it's not a product now.
>
> Despite not being a product, I think it has been a very useful service,
> and should continue to be in the future.
>
> There are several things going on:
>
> 1) Vadim's prototype of Jenkins
> 2) Owen's physical hardware testing (increased scope of Continuous
> beyond just VMs)
> 3) Alex's work on SDKs and app containers
> 4) Discussions around Continuous building other things beyond just GNOME
>
> And there's intersections between these - if we wanted to prototype
> building applications separately from the tree, that cuts across 1 and
> 3.
>
> What I continue to advocate is not for Continuous to become a product
> itself, but for some of the ideas and technology to migrate to
> downstream distributions like Debian and Red Hat Enterprise Linux,
> OpenEmbedded, etc.

I guess my interest is for development purposes - I really want to have 
contiunous development, integration, test and deploy of multiple source 
components easy and fast. GNOME has this problem and Continous has been 
doing some awesome stuff towards this aim.

So from that side, I kinda see Continous as a currently a product in 
that area. I'm not sure how that relates to downstream distros.

> So I now maintain rpm-ostree which is attempting to do just that for one
> of those distributions (and could actually be used by OpenEmbedded if
> you output RPMs there).
>
> The other direction I see is breaking Continuous up into more discrete
> parts (and Vadim's Jenkins work started to do this).  For example, I
> think the git mirroring should be a separate tool/app that sends
> messages to the builder.  The baserock folks have something like this
> split out as "lorry":
> http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/lorry.git/
> Or investigate using Bitbake's git code.

I'd be happy to support folks in reusing lorry.

> I would also like to separate the VM testing infrastructure, as I want
> that also to be useful with rpm-ostree.  If we did that, it'd be awesome
> to make it easier to write tests (beyond just InstalledTests) - things
> like destructive tests.

Absolutely. I have a feeling it'd also make sense to be able to use 
openstack to spin up VMs on demand, as this would allow us to scale up 
more easily. It'd be very cool to have tests parallelized in this way!

> We could bring my work here full circle and look at packaging up
> Continuous as a set of Docker containers (e.g. git mirroring is one
> container, builder is another) ...though I don't know if
> linux-user-chroot would work inside a Docker container.
>
> Any other thoughts?

So one issue I saw Javier hit getting a local copy of Continuous up is 
that only building what changed with no view to dependencies means that 
if Continuous claims to build, that isn't necessarily true.

Having said that, I think a key benefit of Continuous is the fast build 
and test times. As such I think probably you want to have two streams of 
Continous, one giving fast build-one results, and another testing a 
build with dependency follow though.

I think that probably means some hooking up of Continuous with jhbuild. 
And probably some later build caching/fast staging area creation to 
speed up that flow. There's certainly some working out on this side from 
the baserock project that would be useful.

That probably could flow out to multiple streams in general, testing 
say, app builds, sdk builds, etc.

I'd certainly like to set out that we make the current speed a baseline, 
and strive to better that as we develop :)

I hope that makes some sense ;)

Thanks,
Rob