arc/docs/package-automation/the-ci-platform.rst
Ryan Lerch ba720c3d77 fix parsing errors and sphinx warnings
Signed-off-by: Ryan Lerch <rlerch@redhat.com>
2023-11-20 13:04:34 +00:00

50 lines
1.5 KiB
ReStructuredText

The CI Platform
===============
Resources
---------
- Packit + Github:
https://packit.dev/docs/packit-service/#integrating-packit-as-a-service-into-your-project-or-organization-from-github-marketplace
- Packit + Gitlab: https://packit.dev/docs/faq/#can-we-use-packit-with-gitlab
Discussion
----------
This discussion was about which CI platform to use, self-hosted (Jenkins/Zuul), Packit,
Github actions etc.
What would be needed
--------------------
Github
~~~~~~
- Add a `.packit.yaml` file in each repository (those can be created by running `packit
init`);
- A spec file in each repository;
- Organization needs to have packit enabled (we already do).
- Around 31 repositories in total but we are not sure how many of those we can skip.
Pagure
~~~~~~
There is no Pagure support in Packit at this moment, which means we need some
workarounds to make it happen:
- Create mirrors in Github for those repositories;
- Use Jenkins/Zuul to run packit commands;
- Ignore it until we move those apps to something else.
Conclusion
----------
Packit is the right choice for us:
- Packit is available as a "CI Plataform" in both Github and Gitlab;
- It supports multiple "build-systems", such as Koji and COPR and it also supports Bodhi
for package updates;
- All we need is to enable Packit in groups/organizations (already enabled in
fedora-infra Github org) and a yaml file;
- It has a CLI which enables us to re-produce its behavior locally;
- It is not maintained by CPE but the team is close enough to us.