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!
Start the discussion by commenting on the auto-created topic at discussion.fedoraproject.org