fix parsing errors and sphinx warnings
Signed-off-by: Ryan Lerch <rlerch@redhat.com>
This commit is contained in:
zlopez
parent
8fb9b2fdf0
commit
ba720c3d77
98 changed files with 4799 additions and 4788 deletions
|
|
@ -4,26 +4,30 @@ 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.
|
||||
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.
|
||||
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
|
||||
|
||||
- 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.
|
||||
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 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).
|
||||
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:
|
||||
|
||||
|
|
@ -34,64 +38,70 @@ Here is the list of ideas/things we discussed/looked at:
|
|||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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
|
||||
- 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.
|
||||
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.
|
||||
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.
|
||||
- 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.
|
||||
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.
|
||||
- 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);
|
||||
- Git;
|
||||
- YAML;
|
||||
- Basic packit knowdlege;
|
||||
- Basic build tools knowdlege (bodhi, koji, copr, etc);
|
||||
|
||||
Packit + Pagure
|
||||
***************
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
* All of the previous section + Python knowledge.
|
||||
- All of the previous section + Python knowledge.
|
||||
|
|
|
|||
|
|
@ -2,30 +2,35 @@ Packit and Pagure
|
|||
=================
|
||||
|
||||
Resources
|
||||
----------
|
||||
---------
|
||||
|
||||
* https://github.com/packit/packit-service/issues/556
|
||||
- https://github.com/packit/packit-service/issues/556
|
||||
|
||||
Discussion
|
||||
----------
|
||||
|
||||
This discussion is about enabling Pagure support in Packit, what needs to be done and the amount of effort to do so.
|
||||
This discussion is about enabling Pagure support in Packit, what needs to be done and
|
||||
the amount of effort to do so.
|
||||
|
||||
What would be needed
|
||||
--------------------
|
||||
|
||||
Packit team estimates that would be 2-3 months implementation time but prioritization on their side is needed.
|
||||
Packit team estimates that would be 2-3 months implementation time but prioritization on
|
||||
their side is needed.
|
||||
|
||||
The CPE team could contribute to this integration as the Packit codebase is structured in a way that a "Pagure Handler"
|
||||
can be worked in parallel with other Packit code changes.
|
||||
The CPE team could contribute to this integration as the Packit codebase is structured
|
||||
in a way that a "Pagure Handler" can be worked in parallel with other Packit code
|
||||
changes.
|
||||
|
||||
Packit codebase is written in Python: https://github.com/packit/packit-service.
|
||||
|
||||
Conclusion
|
||||
----------
|
||||
|
||||
The CPE could work on this and enable Pagure support, if we really want to invest in Pagure support.
|
||||
The CPE could work on this and enable Pagure support, if we really want to invest in
|
||||
Pagure support.
|
||||
|
||||
The topic of centralizing events in fedora-messaging for all SCMs showed up during this discussion.
|
||||
there were some talks about it but nobody never took the time to work/design it - it is whole new topic that
|
||||
should not be mixed in this work but something to consider for a future initiative.
|
||||
The topic of centralizing events in fedora-messaging for all SCMs showed up during this
|
||||
discussion. there were some talks about it but nobody never took the time to work/design
|
||||
it - it is whole new topic that should not be mixed in this work but something to
|
||||
consider for a future initiative.
|
||||
|
|
|
|||
|
|
@ -2,9 +2,9 @@ Packit Triggers
|
|||
===============
|
||||
|
||||
Resources
|
||||
----------
|
||||
---------
|
||||
|
||||
* Packit Triggers: https://packit.dev/docs/configuration/#packit-service-jobs
|
||||
- Packit Triggers: https://packit.dev/docs/configuration/#packit-service-jobs
|
||||
|
||||
Discussion
|
||||
----------
|
||||
|
|
@ -13,17 +13,20 @@ The discussion was about when and where to push package changes.
|
|||
|
||||
Packit has three event triggers:
|
||||
|
||||
* Pull Requests
|
||||
* Commits
|
||||
* Releases
|
||||
- Pull Requests
|
||||
- Commits
|
||||
- Releases
|
||||
|
||||
The topic showed up because pushing package changes on every and single Pull Requests sound unreasonable in some cases.
|
||||
The topic showed up because pushing package changes on every and single Pull Requests
|
||||
sound unreasonable in some cases.
|
||||
|
||||
What would be needed
|
||||
--------------------
|
||||
|
||||
* PR CI testing is done using COPR, we can centralize those builds in a specific repository if we want to;
|
||||
* Use feature branches to automatically push updates to specific Koji tags (manual releases or commits);
|
||||
- PR CI testing is done using COPR, we can centralize those builds in a specific
|
||||
repository if we want to;
|
||||
- Use feature branches to automatically push updates to specific Koji tags (manual
|
||||
releases or commits);
|
||||
|
||||
Everything is configured in the packit yaml file.
|
||||
|
||||
|
|
@ -32,6 +35,7 @@ Conclusion
|
|||
|
||||
The conclusion is that we all triggers for different scenarios:
|
||||
|
||||
* Pull Requests triggers using COPR for CI RPM test;
|
||||
* Merging of the main branch can push updates to rawhide;
|
||||
* Github releases and/or commits to feature branches could trigger updates in "production koji targets".
|
||||
- Pull Requests triggers using COPR for CI RPM test;
|
||||
- Merging of the main branch can push updates to rawhide;
|
||||
- Github releases and/or commits to feature branches could trigger updates in
|
||||
"production koji targets".
|
||||
|
|
|
|||
|
|
@ -2,45 +2,49 @@ 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
|
||||
---------
|
||||
|
||||
- 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.
|
||||
|
||||
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.
|
||||
- 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:
|
||||
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.
|
||||
- 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 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.
|
||||
- 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.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue