On 08/03/2017 08:32 AM, Josh Boyer wrote:
On Wed, Aug 2, 2017 at 11:15 AM, Dusty Mabe dusty@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.
I believe we want this to be an input, but an input that can be updated by bots. i.e. a new version of rpmxyz is available and a bot opens a PR to add it to the definition of atomic host and tests run on that PR. This is not set in stone, however. Definitely looking from input here, especially from people who know more about modularity.
They can also vary by architecture.
This is something that was previously glossed over in our discussions. Thanks for bringing it up. Does modularity handle this at all today?
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?
Answer was 'input of'. We can debate on whether that is a good or a bad thing :)
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_... [3] https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/... [4] https://docs.pagure.org/modularity/
Atomic Working Group mailing list -- atomic@lists.fedoraproject.org To unsubscribe send an email to atomic-leave@lists.fedoraproject.org
-
Dusty Mabe