On Wed, Aug 2, 2017 at 11:15 AM, Dusty Mabe <du...@dustymabe.com> wrote: > 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.
Is this an output of or input to the compose? I ask because dependencies will change, so assuming they are static would be bad. They can also vary by architecture. > 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. If the answer to the above question is "output of", then this item is essentially a package manifest for everything in the compose, correct? josh > 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/cl...@lists.fedoraproject.org/message/ZS7XY7NHXGGOPOB2YKNQUWSDUGCMYIL5/ > [4] https://docs.pagure.org/modularity/ >
