97 lines
3 KiB
ReStructuredText
97 lines
3 KiB
ReStructuredText
Package Automation
|
|
==================
|
|
|
|
Purpose
|
|
-------
|
|
|
|
Not all Fedora applications are published as RPMs or are not always up to date to their latest code release, automating this workflow would fix that.
|
|
|
|
Other teams would benefit from this work, such as those that build application containers or running integration tests based on RPM releases.
|
|
|
|
Resources
|
|
---------
|
|
|
|
* Packit: https://packit.dev
|
|
* Bodhi: https://bodhi.fedoraproject.org/docs/
|
|
* Packit Pagure support: https://github.com/packit/packit-service/issues/556
|
|
|
|
|
|
Investigation
|
|
-------------
|
|
|
|
The investigation was about testing several tools to accomplish this: Github actions, Jenkins, Packit and Bodhi.
|
|
|
|
Packit does provide a great level of abstraction to both build and publish a package update, integrating with Bodhi and Koji in the way.
|
|
|
|
Packit is also available in both Github and Gitlab as a CI application but not in Pagure (there is an open issue in their repository for implementing it).
|
|
|
|
Here is the list of ideas/things we discussed/looked at:
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
the-ci-platform
|
|
packit-triggers
|
|
packit-and-pagure
|
|
|
|
|
|
Conclusions
|
|
-----------
|
|
|
|
Packit looks to be the path to take, specially because it can integrate with different tools, such as COPR and Bodhi.
|
|
|
|
There is an open questions as how to deal with apps that are hosted in Pagure which are described in the "Proposed Roadmap" section.
|
|
|
|
Proposed Roadmap
|
|
----------------
|
|
|
|
We propose the use of Packit CI Server, usually refered as Packit Service, because it can integrate with both Koji, COPR and Bodhi - it also means that
|
|
we don't need to maintain our own CI service to use packit.
|
|
|
|
Packit CI is also available in Gitlab which means the migration to other SCMs will have minimal impact on this work.
|
|
|
|
Github
|
|
------
|
|
|
|
* Enable/Install Packit Github app: https://packit.dev/docs/packit-service/#integrating-packit-as-a-service-into-your-project-or-organization-from-github-marketplace;
|
|
* Add a `.packit.yaml` file in each repository (can be done with `packit init`);
|
|
* Sample: https://github.com/fedora-infra/the-new-hotness/pull/432
|
|
|
|
Pagure
|
|
------
|
|
|
|
Pagure is not supported in Packit at the time of this writing.
|
|
|
|
There is an open issue on the Packit team side to enable this in Pagure: https://github.com/packit/packit-service/issues/556.
|
|
|
|
This could be an opportunity for CPE to work with the Packit team
|
|
to enable this in pagure, but that will require development effort on our side.
|
|
|
|
We could split the initiative in two phases:
|
|
|
|
* Phase 1: enable Packit in apps hosted in Github;
|
|
* Phase 2: Support Packit in Pagure and enable apps in Pagure to use Packit.
|
|
|
|
Those do not depend on each other and could be worked in parallel but that would mean we need to dedicated more engineers to the initiative.
|
|
|
|
Team
|
|
----
|
|
|
|
* A team of three engineers would be more than enough;
|
|
* One experienced engineer to lead the team.
|
|
|
|
Skills
|
|
------
|
|
|
|
Github Apps
|
|
***********
|
|
|
|
* Git;
|
|
* YAML;
|
|
* Basic packit knowdlege;
|
|
* Basic build tools knowdlege (bodhi, koji, copr, etc);
|
|
|
|
Packit + Pagure
|
|
***************
|
|
|
|
* All of the previous section + Python knowledge.
|