From Fedora Project Wiki
No edit summary
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Objective: Fedora Atomic Continuous Integration workflow, Prototype Phase ==
== Continuous Integration workflow for packagers ==
 


=== Some definitions ===
=== Some definitions ===
Line 10: Line 9:
=== Goal ===
=== 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 is an initiative to improve the quality of Fedora Atomic Host packages by using Continuous Integration. Currently, Atomic Host is automatically tested during delivery, before we "bless" it for users. Continuous integration will bring testing to the front of the process, giving packagers of packages in Atomic Host feedback and gating for each change to those packages.


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.
The testing during continuous integration will provide better quality, and it will enable Atomic Host developers to work on features in Fedora directly rather than pulling changes in at the last minute.


=== Scope and Requirements ===
=== Scope and Requirements ===
Line 18: Line 17:
* We assemble an Atomic Host image and do integration testing on the packages that are contained in that image.
* 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 run for each change of a package that is included in Fedora Atomic Host.


* The tests are stored with or curated in dist-git.
* The tests are stored with or curated in dist-git.
Line 24: Line 23:
* Packagers can change the tests for a given package by pushing a change to 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.
* The 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 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.
* 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 [https://fedoramagazine.org/lets-talk-about-fedora-project-objectives/ blog post] for more on this planning tool.
<!-- SVG source at https://pagure.io/fedora-ci-overview/tree/master -->
[[File:FedoraAtomicCI-logic-model_v1_20170413.png|960px]]


=== Deliverables ===
=== 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.
The primary deliverable will be a functioning set of tools allowing package maintainers to opt-in into testing and gating of package changes.
 
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.
Related 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
== Objective Leads ==
* Having automated testing done for each and every pull-requests
* Having automated merge of each pull-request where the set of mandatory tests passed


== Contacts ==


* [[user:pingou|Pierre-Yves Chibon]]
* [[user:pingou|Pierre-Yves Chibon]]
* [[User:Stefw| Stef Walter]]
* [[User:Stefw| 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.




[[Category:FedoraAtomicCi]]
[[Category:FedoraAtomicCi]]

Latest revision as of 10:32, 28 April 2017

Continuous Integration workflow for packagers

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 quality of Fedora Atomic Host packages by using Continuous Integration. Currently, Atomic Host is automatically tested during delivery, before we "bless" it for users. Continuous integration will bring testing to the front of the process, giving packagers of packages in Atomic Host feedback and gating for each change to those packages.

The testing during continuous integration will provide better quality, and it will enable Atomic Host developers to work on features in Fedora directly rather than pulling changes in at the last minute.

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

Deliverables

The primary deliverable will be a functioning set of tools allowing package maintainers to opt-in into testing and gating of package changes.

Related 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

Contacts

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/FedoraAtomicCI&oldid=491902"