From Fedora Project Wiki

(Created page with "= Upstream = == Objectives == Take advantage of the CI implemented in Fedora to help detect issues with upcoming upstream releases before they get included in Fedora. This w...")
 
 
(One intermediate revision by the same user not shown)
Line 28: Line 28:
# to detect new changes (new proposed changes or new merged changes)
# to detect new changes (new proposed changes or new merged changes)
# to request CI tests
# to request CI tests
# gather CI results
# to gather CI results
# post feedback to the upstream review system for proposed changed or send feedback to the fedora packagers for merged changes
# to post feedback to the upstream review system for proposed changes or send feedback to the fedora packagers for merged changes


To enter into details, if we test all the merged changes the list bellow is correct. Else we'll need either to bisect the changes to detect what caused the problem or let the packagers do the investigation.
To enter into details, if we test all the merged changes the list bellow is correct. Else we'll need either to bisect the changes to detect what caused the problem or let the packagers do the investigation.

Latest revision as of 11:54, 12 May 2017

Upstream

Objectives

Take advantage of the CI implemented in Fedora to help detect issues with upcoming upstream releases before they get included in Fedora. This will leave time to exchange with the upstream projects, prepare for the changes in Fedora in advance and take the right decision to include or not a new release.

The idea is to detect breakages in term of packaging and functionality ahead of including a new release of a package in Fedora.

Design

Integration points

There are 2 integration points that could be used to reach the objectives:

  • before a change is merged in the version control system
  • after a change is merged in the version control system

Testing before is the best to detect an issue even before the change is integrated into the upstream project but unfortunately that's also the more resource intensive. So trade-off will need to be taken according to the available resources in CI.

On-the-fly packaging

Whatever integration point we use, we need a way to package the changes and create a repository with the resulting packages.

Orchestration

The orchestration component needs:

  1. to detect new changes (new proposed changes or new merged changes)
  2. to request CI tests
  3. to gather CI results
  4. to post feedback to the upstream review system for proposed changes or send feedback to the fedora packagers for merged changes

To enter into details, if we test all the merged changes the list bellow is correct. Else we'll need either to bisect the changes to detect what caused the problem or let the packagers do the investigation.

Needs from the CI system

The CI system must be able to consume a custom repository and return the results of the tests on the changed packages.

Recommendation

Comments/Ideas