I still can’t believe that the first half of GSoC period is almost over. So it’s been about 5 weeks working on the project and that means I have a lot to share about it. So without further ado, let’s get started.
I will be listing up my work done in the respective tasks.
Task: Migrating Logins to Salsa
The objective of this task was that the users could log in to their account on debci using their Debian Salsa account (collaborative development server for Debian based on the GitLab software) and this is implemented with the help of OmniAuth, the ruby authentication framework.
At the beginning of this, I had to discuss quite a few issues with my mentors that I was bumping into, and by the end of it with multiple revisions and discussions, the following was implemented:
The previous users' table schema of debci comprises the username field which contained mostly the emails of the users with some exceptions and to accommodate the Salsa logins, a new uid field is added to the table to store the Salsa uid of the logged-in user with the username field storing Salsa usernames now and as the Salsa users have the liberty to change their usernames, the updation of username as well as in debci database is also taken care of.
For Salsa login, the
ruby-omniauth-gitlabstrategy has been used and for login in development mode, the
developerstrategy which comes with
ruby-omniauthhas been set up.
Added a Login Page giving the option to log in using Salsa and an additional option to login in Developer Mode which is accessible only in Development Setup so that other contributors don’t have to set up dummy Salsa applications for working.
Added specs for the new login process. This was an interesting part, as I got the chance to understand RSpec and facilities provided by OmniAuth to mock the authentication for Integration Testing.
One blocker that I dealt with was that the Debian release from where packages were pulled out for debci have the OmniAuth version 1.8, which was not working well with the developer strategy implementation for the application so to resolve that I did a minor change to the callback API for
developerstrategy until the time that release have the newer version of OmniAuth.
Another thing we discussed in one of the meetings that in the existing database structure, the tests do not have a real reference to the users' table and rather the username is stored directly as a string for the requestor field, so this thing was fixed as part of this task.
The migration of the existing users' data for the new logins was handled by my mentor Antonio Terceiro and with this, our first task is concluded. All these changes are now part of Debian Continuous Integration platform and you can find the blogpost for same by Antonio here.
This task also allowed me to write my first ever tutorial Tutorial: Integrating OmniAuth with Sinatra Application to help people looking to integrate their ruby application with OmniAuth.
Moving further to the next task in progress.
Task: Adding support for testing security uploads and Debian LTS
This is the next task I am working on enabling private tests in debci for adding support for testing security uploads and Debian LTS. Since it’s a bigger task, it is broken down into about 6-7 steps and till now, the following has been done:
The schema of jobs' (tests) table is updated to have a boolean field to store whether the job is private or not.
is_privateparameter is added to both API and Self-Service section so the private test can be submitted through the API as well as through GUI form on the web platform.
Another thing which comes up through discussion in meetings that a parameter is required to add
extra-apt-sourcesfor getting packages of security repository and this is the part in progress.
So that concludes my work till now. It has been an amazing journey with lots of learning and also the guidance from the wonderful mentors of my project and I am looking forward to more exciting parts ahead.
That’s all for now. See you next time!