This document concerns requirements from Fedora infrastructure, release engineering, and other community teams for a CI implementation in Fedora. It exists to help projects understand what the requirements are for integrating a CI and/or CD pipeline with Fedora.
Definitions/assumptions
- The Fedora infrastructure team is a community team. It’s mostly staffed by Red Hat employees but also includes volunteer members of the Fedora community.
- The team has a set of agreed on standards to ensure maintainability with limited resources, and to provide a reasonable on-ramp for community, since one of the Fedora Engineering team’s goals is to promote growth of the “farm team” of new community members. Most of these standards are available online. Expanding the app/service development standards explicitly is part of the FY2018 roadmap for our team.
Requirements for Fedora to maintain Infrastructure
Services running in the Fedora Infrastructure must be fixable and maintainable by the Fedora Infrastructure team. Tools must therefore employ paradigms and be written in languages understandable by the members of that team. In practice, critical tools running in the Fedora infrastructure and maintained by the Fedora Engineering team are usually written in Python. Other tools may be accepted by the team on a case by case basis. Services intended to run in the Fedora infrastructure are proposed in the RFR process.
Requirements for Infrastructure run outside of Fedora
- Tooling/services run outside of Fedora must have agreements or expectations for maintenance and response time before Fedora processes can rely on them.
- A gating pipeline which is not run by the Fedora infrastructure must have an agreed or expected service level that has been accepted by the Fedora infrastructure team. This may require headcount assigned to active maintenance.
- Every tool used by Fedora (whether hosted in or out of Fedora Infrastructure) must be FOSS and public.
Requirements for gating and packager feedback
- It must be possible to represent CI test results in resultsdb.
- Test result messages must be sent via fedmsg notifications and follow the documented interface.
- Tests which gate or provide packager feedback stored in dist-git must be written in the agreed standard interface.
- Tests which gate or provide feedback but are stored outside dist-git must use the same triggering and results reporting mechanisms, be open source, and will be integrated into the gating on a case by case basis.
- All parts of all tests and inputs to tests must be open source and publicly accessible.
- All test results and test logs need to be public.
- Packager feedback from integration tests must occur prior to the merge of dist-git commits. This prevents packages which fail early required testing from entering any potential updates stream.
- The CI pipeline must be possible to use by any package and packager in Fedora (with a mechanism to opt-in and a mechanism to enforce it)
Requirements for automated Fedora delivery of artifacts from pipeline
These requirements may need to be met by Fedora Engineering, by those working on a CI pipeline implementation in Fedora, by RCM development, or by other stakeholder teams.
- The compose process should be flexible enough to compose only based on changed inputs that are configured to be included in that compose.
- All the tools used in the pipeline must be free and open source.
- All inputs used by tools run by the pipeline must be publicly accessible.
- Tools run by the pipeline should be runnable and reproducible outside of the pipeline.
- All inputs to tools run by the pipeline must be recorded, and transformations run in the process must be recorded, along with the outputs of the tools run by the pipeline.
- Output artifacts for delivery must be registered with content generators.
- Actions performed by users (humans or robots acting on the pipeline) must be recorded (accountability)
- Identical inputs must deliver the same outputs (reproducibility) with any differences justifiable upon examination.
- Multi-arch support should be considered when designing any tool or piece of the pipeline.
- Tool design or pipeline implementations should not preclude multi-arch support.