This week in the project, we covered the changes on how we handle the pull request to make it a more intuitive process.

No config? No problem!

One of our key goals is to reduce friction for contributors as much as possible. With that in mind, my mentor suggested we align our required file structure with the standard dist-git layout, which defines a package simply with a specfile and patches for the upstream source.

Previously, our service required a packit.yaml configuration file in the repository just to trigger COPR builds and Testing Farm jobs. We have now eliminated this dependency. By parsing the specfile directly from within a pull request, our service can infer all the required context automatically. This removes the need for any boilerplate configuration.

Small troubles

As I have mentioned before that we are currently using the rawhide container images for development, since the current stable Fedora release does not have the required versions of the python bindings for forgejo.

The problem was I was running a dnf update before installing anything in the container and for some reason ca-certificates got upset in the container, which caused the service to not be able to communicate over the network.

With some hit and trial, I discovered that removing that line and simply just not updating can work. That fixed it for now, but the good news is Fedora 43 is going to enter a Beta or a package freeze phase so there should not be any such problems now.

What’s Next?

With these core features now in place, my focus for the upcoming weeks will be on two main tasks:

1. Documentation: I’ll be writing documentation for the service, covering its usage for end-users and development guidelines for future contributors.
2. Upstreaming Code: The final step is to contribute the Forgejo integration code back to the upstream OGR and packit-service projects so the wider community can benefit from the forgejo integration, still in progress.