owned this note   changed 5 years ago  
Linked with GitHub

On-boarding new CI systems in Fedora

This document is a work in progress, some part of it are quite stable, other will changed without notice.

Please do not rely on it for anything without explicit agreement.

This document describes the requirement for on-boarding/adding a new CI system in Fedora and have it be considered for gating packages.

The unit of change

Fedora has a few places where changes happen, there is the git repository storing the spec files and patches. There is the build system where artifacts are built and there is the update system where artifacts are pushed to our users in the form of updates.

There is however no one to one relation between a commit and an update. A commit can be built but does not have to. A build can be turned into an update but does not have to.

Therefore it is important to consider what is the unit of change your CI system will test.

Currently the system is designed around the concept of NVR (name-version-release) which apply to the RPM ecosystem.

We recommend that updates (ie: bodhi updates) be the unit of change.

Triggering the tests

You will want your CI system to trigger its tests based on messages sent on the Fedora message bus.
The Fedora message bus is a rabbitmq message broker.

The fedora-messaging library has been developed to help standardize and make interaction with that broker easier.
While helpful and recommended, its use is not mandatory.

From the update system

There is currently a dedicated message sent by bodhi (the update system) to inform the CI systems that an update is ready to be tested.
This message has for topic: org.fedoraproject.prod.bodhi.update.status.testing.koji-build-group.build.complete

You can find example of these messages in datagrepper: https://apps.fedoraproject.org/datagrepper/raw?topic=org.fedoraproject.prod.bodhi.update.status.testing.koji-build-group.build.complete

From the build system

If you really want to run the test for every build made, you can trigger of the messages sent by the build system:

You can see in these messages a state field, here is what it corresponds to (from the koji python module):

   >>> import koji
   >>> koji.TASK_STATES
   {
       'FREE': 0,
       'OPEN': 1,
       'CLOSED': 2,
       'CANCELED': 3,
       'ASSIGNED': 4,
       'FAILED': 5,
   }

From the commits

If you really want to run tests for every commit made in the git repositories, you can trigger of the messages sent by dist-git:

Reporting test results

Test results from your CI pipeline should be published on the Fedora message bus.
Depending on how/where your tests are running, you may already have certificates to sign your messages be allowed to send messages to our broker.

If you do not, you will need to open a ticket in the fedora-infrastructure tracker: https://pagure.io/fedora-infrastructure/new_issue

Topic of the message

The topic of the message should follow these basic principle:

  • Message topics are for clients to filter messages on, so they should be about important parts of the message.
  • A message from a service should likely start with the name of that service
  • Clients are probably also interested in filtering messages by status, so it could include a segment with queued, running, completed, failed, canceled, or similar.
  • Clients are probably also interested in filtering messages by subject (the artifact tested) so including it in the topic is helpful.
  • It's best to start more general and get more specific for each section of the topic.
  • Topic lengths are limited to 255 characters
  • For historical reasons, topics have been prefixed with where they originate from: org.fedoraproject.{prod,stg}, org.centos.{prod|stg}, io.pagure.{prod|stg} and so on. This structure is still expected by some of our apps so please respect it for now.

For details on AMQP topic rules, see https://www.rabbitmq.com/amqp-0-9-1-reference.html#queue.bind.routing-key.

While there is currently no generic pattern to follow for the topic of CI systems. We are considering it and may thus adjust this document accordingly.

Content of the message

The OSCI team at Red Hat, has come up with a standardized format, enforced with a JSON schema, which contains all the information (and more) needed for your test results to be considered for gating.

Please use the following example:

This repository also contains schema and examples if you wish to report test results for a single build or for a commit.

Integrating into Fedora's gating

Fedora is gating its updates using the duo: greenwave and waiverdb.
greenwave queries resultsdb for test results about the artifact of interest and makes a decision about it considering configured policies, the test results and the waivers submitted.

Greenwave's decision is what leads to updates being gated or not.

So for your results to be evaluated, they need to be uploaded to resultsdb. This is achieved by resultsdb-listener which listens for certain messages on the bus and as it sees them, upload them a results into resultsdb.

If your messages are following the schema described in the previous section, adding support for your CI system to resultsdb-listener should be as simple as adding the topic you're sending and a unit-test for it. Otherwise, a little more coding will likely be needed. In all cases, unit-tests will be asked.

Questions?

If you have any question about this document, please contact us using the Fedora CI mailing list: https://lists.fedoraproject.org/archives/list/ci@lists.fedoraproject.org/

Select a repo