CI.new

Why

Vision

There are hundreds of packages which make up the Operating System. Making sure that they all work together as a whole is not an easy task. This becomes even harder as the number of packages and their inter-dependencies grows. An extensive testing is required before a new version of the operating system is released to ensure it is stable enough. That is the past.

Imagine an Always Ready Operating System which consists of packages which are constantly kept in a good shape. Integrated and stable thanks to an extensive test coverage which is continuously executed upon changes in individual packages, in this way allowing to prepare a new release in much shorter time, or even in no time.

Imagine an operating system distribution which you could release at any moment. This is where we are heading. Here comes the CI, Continuous Integration, as an invaluable tool to ensure everything is working together as expected in every point of time.

Manifesto

Continuous integration aims to ensure broken changes are revealed as soon as possible and do not affect other developers, packagers, maintainers or users. The feedback that continuous integration provides is vital for fast paced agile delivery of software. Late testing, long after a change occurs, does not scale to the pace of Fedora. Learn the goals, terminology and rules for a working CI in the manifesto.

• Continuous Integration Manifesto

How

There are three main pieces of the puzzle to get this nicely working: A process which clearly defines how to discover and execute tests, a set of tools which help to efficiently implement the process and the tests themselves.

Process

Standard Test Interface

In order to clearly distinguish test from the CI system running it the Standard Test Interface was introduced. It clearly defines essential terms such as test, test subject, test suite, test framework, test result, test artifact, test system and describes what are their responsibilities and requirements.

This general approach gives a nice flexibility as it does not enforce any specific tools or frameworks to be used. Basically it only describes how tests are discovered and where the testing results should be stored to be processed by the automation.

• Standard Test Interface

Gating Updates

When a test fails, CI can prevent the broken change from affecting other packages. That gating happens in Bodhi.

• Gating Updates
• Proposals and options

Notifications

Fedora Notifications have been adjusted to notify by default every packager when any step of the CI pipeline fails on one of the package they maintain. So if you are a kernel maintainer and a commit made to the kernel dist-git repository fails to compose an OSTree, FMN will notify you of it.

Bodhi includes the CI results in its update page, just as it already includes tests results from taskotron.

Tools

Standard Test Roles

Standard Test Roles were implemented to enable both automation tools and developers in their local environments to easily execute tests. This set of ansible roles supports various frameworks and allows to execute tests against different test subjects (such as classic rpm package, docker container or Atomic Host).

• Standard Test Roles

Pipeline

The testing Pipeline detects tests for enabled packages, executes the test coverage and gathers the results.

• Pipeline

Pagure

Test results from the CI pipeline are displayed in Pagure web interface. See the commits page of respective package. Currently tests are scheduled for new commits in branches only. Support for pull request testing is planned in the near future.

• Pagure

Tests

The core of the CI success are reliable tests of a good quality, well selected, stable, organized and continuously maintained.

Test Types

In general it makes sense to store tests as close to the upstream as possible. So what are the appropriate test types recommended for testing the Always Ready Operating System?

• Basic functionality tests
• Integration tests

For unit tests it usually makes more sense to store them directly within the upstream project repository. However, in some cases it might be worth to fetch tests for Fedora CI from the upstream repository as well.

Test Code

Tests may be written all sorts of different ways, but have to be exposed and invoked in a standard way. Tests are enabled by including the tests/tests.yml file in the package dist-git repository as defined by the Standard Test Interface. Test code itself can be stored directly in the dist-git or fetched from another repository. Shared tests namespace can be used for storing test code relevant for multiple packages.

• Tests ... How to run, write and wrap tests
• Shared Tests ... Shared tests namespace

Test Execution

Executing a test written with the use of Standard Test Roles is as simple as running an ansible playbook ansible-playbook tests.yml. However, a set of environment variables needs to be set properly in order to execute the test against the desired test subject. The Tests wiki contains detailed instructions about running tests and adding new test coverage.

• Tests ... How to run, write and wrap tests

More

Contact

If you have questions or would like to get involved:

• IRC channel: #fedora-ci on FreeNode
• Mailing list: ci@lists.fedoraproject.org
• Issues: pagure.io/fedora-ci/AtomicCi

Links

Here's a summary of useful links:

• Standard Test Interface ... definition of the process
• Standard Test Roles ... set of ansible roles
• Pipeline ... CI pipeline executing the tests
• Tests ... executing and adding tests
• Upstream First ... tests to be ported to dist-git

FAQ

• Where do I get the latest Atomic Host images for testing?