Future directions for Continuous



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.

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

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?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]