(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...") |
m (→Orchestration) |
||
| (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 | # 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:
- to detect new changes (new proposed changes or new merged changes)
- to request CI tests
- to gather CI results
- 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.