package automation
This commit is contained in:
parent
7f376cf928
commit
daf8c47acf
4 changed files with 211 additions and 0 deletions
97
docs/package-automation/index.rst
Normal file
97
docs/package-automation/index.rst
Normal file
|
@ -0,0 +1,97 @@
|
|||
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.
|
Loading…
Add table
Add a link
Reference in a new issue