Changes/FedoraAtomicCI

Objective: Fedora Atomic Continuous Integration workflow, Prototype Phase

Some definitions

• Continuous Integration:
  • Integration: Assemble it together like in production, then test drive it like a user. This is Integration.
  • Continuous: Do those integration tests for every single "change". This is Continuous.

Goal

This is an initiative to improve the production of Fedora Atomic Host by using Continuous Integration. Currently, Atomic Host is automatically tested at the end of the pipeline, before we "bless" it for users. CI will bring testing to the front of the process, giving faster feedback to developers. Earlier testing will provide better quality, and it will enable Atomic Host developers to work on innovations in Fedora directly rather than pulling changes in later.

This will also serve as a testbed for possible CI workflows for other Fedora Editions and Spins, and possibly even across the project in general. For instance, a CI pipeline could be used to produce a more reliable daily Rawhide stream.

Scope and Requirements

• We assemble an Atomic Host image and do integration testing on the packages that are contained in that image.

• The tests are run for each commit pushed to dist-git for a package that is included in Fedora Atomic Host.

• The tests are stored with or curated in dist-git.

• Packagers can change the tests for a given package by pushing a change to dist-git.

• The initial set of packages we're interested in are those in Atomic Host.

• Packagers get quick feedback on whether a change to a package fails.

• Packagers must be able to opt into CI testing and gating on the tests.

Logic Model

The basic idea: planning flows from right to left, and actual effort back from left to right. To the left of the double line is stuff we can actually do; to the right of that line, stuff we expect to be true as a result. See this blog post for more on this planning tool.

Deliverables

The primary deliverable will be a functioning set of tools allowing package maintainers to opt-in into a pull-request based package maintainance model introducing on new level of gating: at the change in dist-git/pagure.

As part of making this prototype, other deliverables include:

• having pagure as a front-end to dist-git
• having a system where packager can contribute and configure tests for their package of interest
• having automated testing done for each and every pull-requests
• having automated merge of each pull-request where the set of mandatory tests passed
• start of a pipeline allowing to do CI in Fedora, that we should expand outside of Atomic images

CI Working Group

Effort on this Objective will be undertaken by a new "CI Working Group". This group is not yet clearly defined but will include people from the Fedora Engineering team and coordination with the Fedora Release-Engineering team and the people involved in the Factory 2.0 work.

The effort will also require help and resources from across Fedora, including Fedora Infrastructure, Release Engineering, QA, Security Team, and more. Representatives of those groups should be included on the new Working Group.

Objective Leads

• Pierre-Yves Chibon
• Stef Walter

Timeframe

The prototype should be available around the time of the Fedora 27 release. We should be able to report progress at Flock in August 2017 and demo it at FOSDEM and/or DevConf 2018.