Hi, I am Mayank Singh, welcome back to this blog series on the progress of the new package submission prototype, if you aren’t familiar with the project, feel free to check out the previous blogpost here.

Extending Forgejo support

As Forgejo is expected to become the git forge for Fedora in future and based on community discussions. I thought it did be great to support Forgejo in this project.

packit-service supports both GitLab and GitHub thanks to OGR library. It provides a unified interface for interacting with git forges.
The library has a good support for GitHub and GitLab features but the Forgejo integration is still not quite on par with them, few important functions like adding comments and reactions are still missing.
I worked on adding the support for the necessary parts so that packit-service can work with Forgejo.
There are few bugs related to serialization in the code, which I plan to fix this week.

New Package Builds from New Pull Requests

I’ve added a simple handler to read from a new Pull Request and its description to parse packit commands. This allows users to trigger a build for a new package without needing a packit configuration file in the repository.

For example, adding this line the PR description will trigger a new build for this particular package name.

/packit copr-build package_name: <libexample>

The system dynamically constructs a minimal package config and feeds it into Packit’s internal build logic. Test jobs are expected to work as well, although this is yet to be fully verified.

The current implementation is a quick prototype that reuses as much of the existing packit-service logic as possible. There’s still more work to be done around building the full package context.
My mentor has also shared feedback suggesting a cleaner approach, which I’ll be iterating on in the next phase.

What’s Next?

• Fix remaining serialization bugs.
• Build and test the Testing Farm integration for running test jobs on the built packages.
• Improve the source handling logic based on recent feedback.

Thanks for reading and stay tuned for more next week.

This week in the project involved bug fixes, integration cleanup and small improvements.

Bug Fixes and Workarounds

A key function required for the Forgejo integration which is used to fetch files from repositories was broken in the current Fedora 42 release due to an upstream bug in Forgejo’s OpenAPI spec. While the bug is already fixed in newer versions, it couldn’t be backported cleanly due to dependency constraints.

To move forward, I upgraded the service to run on Fedora Rawhide. However, Rawhide had its own quirks, the celery package was broken. To work around this, I installed celery directly from PyPI instead, which resolved the issue for now.

There were also several issues related to how data was being passed between the celery tasks. In particular, raw comment objects from Forgejo events were being passed around, which are not JSON-serializable and caused failures. With help from my mentor, added fixes in the logic to ignore the problematic object from being included in the payload.

Improvements and features

Enabled the `fedora-review` tool for all COPR builds in the codebase by monkey-patching the API call to enable fedora-review, which is not available directly otherwise from the packit API. This allows us to get a list of tasks and requirements for Fedora packaging compliance for the corresponding build of the package.

As of now, COPR builds and testing of the builds work. I started working on status reporting, it’s still rough, and I attempted to get comments working, but I’ll need to add more support in the OGR library to implement commit status properly.

What’s Next?

• Add support for Forgejo commit status API.
• Comments about status and builds from the service
• Add unit tests for the new functionality
• Upstream Forgejo code to packit-service

Hi everyone, I am Mayank Singh, currently working on a new service for simplifying the Fedora Package Submission Process, if you’d like to know more check my previous post here.

Diving Deep into Packit Service

(27 June – 8 July):

I began working on the packit-service codebase as the foundation for our project. The first goal was to prototype the user flow by creating new APIs and handlers for functionalities like detecting new packages and linting.

Pretty early on, I hit a roadblock during a test run. When the service was deployed to listen for GitHub events, it wouldn’t reject any incoming events sent through the tunnel to the local deployment. After a lot of digging, I traced the issue to the Apache configuration in the mod_wsgi-express server. This server, responsible for serving the Flask-RESTx endpoints, was misbehaving and causing all the trouble.

Another hiccup was that the service was too heavy for my system to run locally in an OpenShift environment with GitHub. My mentor stepped in and suggested a helpful workaround, disable the unnecessary services for our use case and use GitLab instead in plain docker containers, as it’s much easier to spin up and test locally. Reported a few other problems in the deployment process for development regarding Bitwarden for secrets.

With those issues resolved, I went ahead and trimming the parts of the packit-service codebase that weren’t needed for onboarding new packages. This helped me better understand its event model and the use of Celery in task execution.

This week was mostly about reusing the existing packit-service codebase and resolving issues.

What’s Next?

With the hard parts of setup and architecture done, the next steps would be to:

• Add new API endpoints and corresponding event types for task handling

• Integrate the current setup with COPR for builds.

• Begin work on testing and validation workflows

Stay tuned for more updates in the next blog post!