- Name: Mayank Singh
- Email: mr.mayankgame@gmail.com
- GitHub: https://github.com/mynk8
- Organization: Fedora Linux
- Project Repository: https://github.com/packit/avant
- Mentors: František Lachman
- Project Duration: 350 hours
The project introduces a proof-of-concept, Git-based workflow for the Fedora package review process, offering an alternative to the older Bugzilla-based system.
Contributors can now create, submit, and manage their package reviews through Pull Requests in a centralized Forgejo repository. The service handles package building, testing, and compliance checking with the fedora-review tool, posting real-time status updates directly to the PR page.
This integration of Git with automated tooling into a single platform significantly lowers the barrier for new contributors to get their packages into the distribution.
The traditional workflow for submitting a new package to Fedora was fragmented and tedious, relying on a manual process involving .spec files, external file hosting, and Bugzilla tickets. The old process required manual Bugzilla tickets and external file hosting, which had slower feedback loops, often discouraging potential contributors.
This project was motivated by the critical need to modernize this experience. By creating a centralized, pull-request based workflow, the goal was to lower the barrier to entry for people with less experience in packaging and improve the overall efficiency of the Fedora package ecosystem.
The key objectives were:
-
Demonstration/Prototype: A fully functional proof-of-concept service was developed. The entire user journey, from a local commit to receiving automated results, is operational and detailed in the Walkthrough section of this report.
-
Source Code Repository: The project's source code can be found at avant, with certain parts contributed to established, public Fedora tooling. This includes feature additions to the packit-service repository and its ogr dependency to implement the Forgejo integration.
-
Integration of Automatic Checks: On every new commit to a PR, the service automatically triggers COPR builds, runs installation tests via Testing Farm, and performs compliance checks with fedora-review, posting all results directly to the PR for immediate review.
-
Deployment: The service is containerized and ready for deployment. A ticket has been opened to run the service publicly on Communishift.
-
Testing and Documentation: Setup instructions for service secrets are similar to those for packit-service. A comprehensive user walkthrough and usage guide are included. The project uses validation tests to ensure that COPR and Testing Farm jobs run as expected.
A simple walkthrough of the service.
The journey begins in a familiar Git environment. A contributor starts by forking the central review repository to create their own personal workspace. In their local clone, they add the essential packaging files: the .spec file that defines how the package is built and the sources file containing the upstream code.
Once the files are ready, the contributor commits their changes and opens a Pull Request against the main repository. This single action is the trigger that brings the entire automated review system to life. No more Bugzilla tickets or manual uploads—the PR is now the central hub for everything that follows.
Immediately after the PR is opened, the service gets to work. The contributor can see real-time status checks appear directly on the PR page, starting with the SRPM build.
When the checks are completed, the service posts a comment with the results of the fedora-review tool. This provides immediate, actionable feedback, clearly categorizing issues into "must," "should," and "extras," so the contributor knows exactly what to address.
One can inspect the list of checks that failed, are pending, and are also categorized by "should," "must," and "extras." After a while, rpmlint and install checks are finished; they are failing in this case.
We can inspect the logs by clicking the "Details" link, which redirects the user to Packit's dashboard.
Checking the latest entry here, we can find the Testing Farm run and inspect the logs to trace the cause of failure. We can see that the checks failed due to a broken package and missing dependencies.
The reported problems can then be fixed locally, push the changes, the checks run again to provide feedback again.
With clear logs and feedback, the contributor can fix the issue in their local repository and simply push a new commit. The service automatically detects the change and re-runs the entire suite of checks, providing updated feedback.
This creates a tight, rapid feedback loop. Experienced packagers can also join the discussion directly in the PR, reviewing the code and inspecting the same test results, making collaboration seamless and efficient.
| Dates | Milestones & Goals |
|---|---|
| June 27 - July 7 | Foundation & Architecture • Present high-level architecture to Fedora community • Decide on monorepo model for package submissions • Set up local development environment with packit-service• Begin prototyping user flow with new APIs and handlers |
| July 8 - July 15 | Forgejo Integration & Event Handling • Migrate service forge to Forgejo (open-source alternative to GitHub) • Add support for parsing issue and push events • Implement parsing commands from issue comments • Resolve technical challenges with package source handling |
| July 15 - July 22 | Core Functionality & Build System • Extend Forgejo support in packit-service• Write sample handler for reading from new Pull Requests • Enable dynamic package config construction for builds • Get COPR integration running for package builds |
| July 22 - July 29 | Status Reporting & Integration • Implement commit status reporting for package actions • Add support for Forgejo commit status API in ogr library• Enable fedora-review tool for all COPR builds• Begin work on status reporting and comments |
| July 29 - August 7 | Enhanced Status & Feedback • Complete commit status implementation for Forgejo • Report build and test results directly to PRs • Focus on comment functionality and status updates • Begin unit testing for new functionality |
| August 7 - August 14 | Workflow Optimization • Eliminate requirement for packit.yaml configuration• Align with standard dist-git layout• Parse specfile directly from PRs • Resolve container and dependency issues |
| Aug 14 - Aug 22 | Testing & Reporting Improvements • Implement separate status reporting for rpmlint and installation tests• Switch to JSON-based fedora-review reports• Improve comment formatting with collapsible sections • Work on unit testing challenges |
| Aug 22 - Aug 29 | Final Integration & Documentation • Complete Testing Farm integration • Finalize automated review workflow • Prepare project demonstration |
August 29+ |
Deployment & Upstream Contribution • [Pending] Deploy service containers for public use on Communishift fedora-infra ticket • Configure validation tests • Write documentation • [Pending] Merge Forgejo integration code into upstream. #2835 and #896 |
- Git Forge Integration: Gained a deep understanding of interfacing with Git forges by contributing Forgejo support to the
ogrlibrary. - Container Orchestration: Developed skills in managing containerized services, secrets, and resolving deployment challenges on Communishift (OpenShift/Kubernetes).
- Asynchronous Service Debugging: I got much more comfortable debugging async services, especially when failures couldn’t be reproduced locally.
- API and Webhook Handling: Learned best practices for parsing, digesting, and securely handling webhook data from external services.
This service provides a strong foundation for further innovation. Future enhancements could include:
- Automated
dist-gitOnboarding: Extending the service to automatically create a newdist-gitrepository and push the approved package upon PR merge. - Monorepo Dependency Handling: Supporting complex scenarios where a submitted package has dependencies that also exist within the same PR or needs review.
- František Lachman: Grateful for the constant support and guidance throughout the project.
- Fedora Community: For their support, discussions, and feedback that helped shape the project.
Overall, GSoC was a great learning experience for me.