[atomic-devel] Meeting item for 20170802: Atomic Host + Modularity - Enabling CI/CD

[Dusty Mabe <dusty dustymabe com>]

Recently we talked about adding more CI/CD to the Atomic Host
processes. Since we release every two weeks we'd like to automatically
run tests on every change that goes in to Atomic Host and prevent
it from going into Atomic Host if it causes test failures. 

This was suggested to the Atomic Working Group from the new CI Working
Group [1] in the 2017-07-12 meeting [2]. Stef, from the CI working
group also sent a mail to the cloud list about it [3].

Here are some of the things we want to be able to do:

1  Have a rigorous definition (including specific versions, buildroot) of
   what goes into an Atomic Host, including dependencies.

2  Triggering the CI/CD pipeline based on a change to definition 
   of what goes into Atomic Host.

3  A way to revert a package in the Atomic Host compose to an earlier version.

4  A place to store higher level tests along with rigorous definition
   of Atomic Host, including them being versioned.

5  Landing multiple changes that need to land together to pass testing.


Out of that list we think we require that:

1R The definition of what is composed into Atomic Host artifacts should 
   include specific versions of packages, and all dependencies included.

2R The definition of what is composed in an Atomic Host should be stored
   in a git repository so that changes can be detected easily. The
   CI/CD pipeline can be triggered off of changes to this reposiroty.

3R A mechanism to make a future composed Atomic Host artifact, contain
   an earlier (in RPM NVR parlance) version of a package.

4R The high level functional Atomic Host tests should live in the same
   git repository with the rigorous definition of what goes into an Atomic
   Host.

5R A mechanism to tell the CI Pipeline that multiple dist-git repository
   changes (i.e. multiple changing RPMs) should be built and tested together.

We believe that moving to an Atomic Host defined by a module [4] can
satisfy our needs and enable the improved control of artifacts within
Atomic Host as well as the improved triggering and coupling with a
testing pipeline that will help us move forward. Since modularity is new
this will take some experimentation to prove out. Let's chat about this
in the Atomic Working Group meeting today at 1700UTC in #fedora-meeting-1.

Dusty


[1] https://fedoraproject.org/wiki/CI 
[2] https://meetbot.fedoraproject.org/fedora-meeting-1/2017-07-12/fedora_atomic_wg.2017-07-12-17.00.log.html
[3] https://lists.fedoraproject.org/archives/list/cloud lists fedoraproject org/message/ZS7XY7NHXGGOPOB2YKNQUWSDUGCMYIL5/
[4] https://docs.pagure.org/modularity/