GSoC 2020 Progress Report: Dashboard for Packit (Fedora Project) (July 1 - Aug 16 2020)

Also posted at https://communityblog.fedoraproject.org/gsoc-progress-report-dashboard-for-packit-july-1-aug-16-2020/

Hi! I am Anchit, and I’m working on the dashboard and the API for Packit Service. If you’d like to know more about me or this project, check out my previous post here.

About Packit Service

Packit-as-a-Service is a GitHub App that helps developers continuously ensure that their project works in Fedora. Packit Service validates pull requests by building that project in Fedora so that others can install and test those built rpms before merging.

July

Week 5 (29 June - 5 July): The new API endpoints were up and running but I noticed a problem. When the API was pinged multiple times simultaneously, it failed to return something. It took a while for us to figure out the exact issue so I implemented caching and retries in the dashboard as a temporary solution to prevent it from randomly failing. My mentor (Hunor) however was reluctant to use this and wanted a more permanent solution.

After some digging he realized that we were using a single sqlalchemy session object for all threads and this led to a race condition where commit() was being called twice on the same transaction. So I read more documentation and implemented thread-local sqlalchemy sessions.

Week 6 (6 July - 12 July): I wrote some queries to fetch data from the database and built the following API endpoints (and tests, ofc):

  • /api/projects
  • /api/projects/<forge>/<namespace>/<repo_name>/prs
  • /api/projects/<forge>/<namespace>/<repo_name>/issues
  • /api/projects/<forge>/<namespace>/<repo_name>/releases

Week 7 (13 July - 19 July): Using the /api/projects/... endpoints I made in the previous week, I built the projects view of the dashboard. I also made a new API endpoint, /api/projects/<forge>/<namespace>/<repo_name>/branches.

I broke (and later fixed) somethings because of my incorrect understanding of JobTriggerModel, which is a thing we use in our database and it follows a different design pattern than what I was used to.

Week 8 (20 July - 26 July): I wrote some tests, made some random enhancements to our API including a wrapper function for the actual API response which made the API code cleaner.

Week 9 (27 July - 2 Aug): Misc changes to the dashboard including wildcard search for projects. Here’s how the dashboard looks as of Aug 3:

August

Week 10 (3 Aug - 9 Aug): Stranger6667 from the Schemathesis project informed us that our generated API schema was violating some REST guidelines so I fixed those.

Nest! This was the first Fedora event that I’ve attended. I met the other GSoC/Outreachy/Red Hat interns on a social call organized by Vipul and Marie. It was fun. I also saw some talks and met a bunch of cool people. All in all, I enjoyed Nest.

Week 11 (10 Aug - 16 Aug): On 13th Aug, all the GSoC/Outreachy interns had a call with the Fedora Council. We talked about our project and takeaways.

I spent some time linking SRPM Builds stored in our database to JobTriggerModel (yeah the same thing which I had trouble understanding earlier) so that we can access them without relying on Copr Builds stored in our database. I also wrote schema and data migration scripts. Then I used all this to build the /api/srpm-builds endpoint.

Looking Forward

I had a great time working with the team and am looking forward to learning more cool stuff.


Last modified on 2020-08-17