feat(ci): Create Fedora RPMs using Packit

[bkmgit]

Add a pipeline to enable builds using https://packit.dev/ on generation of Fedora RPMs on each commit,

To get it to work, someone with commit access will need to agree to make a Fedora account at:
https://accounts.fedoraproject.org/

and agree to Fedora Code of Conduct, then follow the steps at:

http://packit.dev/docs/guide#1-set-up-packit-integration

• I ran valgrind when using my new feature

How to test the functionality

• If CI passes, testing RPMs for Fedora will be created.
• Install built RPMs on a machine running Fedora.

[jubalh]

What is the purpose of these rpms? It's for testing whether rpm building works?

[bkmgit]

A user had indicated wish to use very latest version. Since distro policies prefer stability in packaged versions in releases, thought it would be useful to make these available here.

OBS seems to have something similar:
https://openbuildservice.org/help/manuals/obs-user-guide/cha-obs-scm-ci-workflow-integration.html

[jubalh]

OBS has a feature where you install a webhook, and upon each commit (to master or where you define it) OBS will build a new rpm. This rpm is stored/retrievable from OBS.
So basically OBS will do everything and on the GitHub site you have just the trigger for the webhook.

Is it the same with this solution here?

With OBS we wouldn't have to add a spec file to the upstream project. This would be stored in the OBS package. It then automatically pulls the sources from upstream when a webhook arrives and creates a tarball from them. This has the advantage that the same spec file like for distribution packaging can be used without upstream having to keep them in sync.

[bkmgit]

OBS has a feature where you install a webhook, and upon each commit (to master or where you define it) OBS will build a new rpm. This rpm is stored/retrievable from OBS. So basically OBS will do everything and on the GitHub site you have just the trigger for the webhook.

Is it the same with this solution here?

Very similar.

With OBS we wouldn't have to add a spec file to the upstream project. This would be stored in the OBS package. It then automatically pulls the sources from upstream when a webhook arrives and creates a tarball from them. This has the advantage that the same spec file like for distribution packaging can be used without upstream having to keep them in sync.

The built RPMs would be on Fedora infrastructure. There would be a message on each pull request if tests ran successfully. If you wish to have them on OBS, that is fine. The Fedora and Suse spec files have some minor differences, can keep them separate, or add some #ifdef statements.

[jubalh]

There would be a message on each pull request if tests ran successfully.

Is there another project where I can see how it looks/works?

If you wish to have them on OBS, that is fine.

Personally I don't care, I would just like to omit to have to keep the spec file up to date.

[bkmgit]

Some examples:

• Remove patch from spec file bkmgit/python-colormath2#15
• cli: Add --sp and mesh stopper calibaration enactic/openarm_can#135

It does seem possible to automate spec file updates using https://github.com/packit/specfile

Am willing to explore OBS as well.