The theme for this week in Outreachy is “Think About Your Audience”. So I’m currently thinking about you.
After being asked sooo many times what am I doing for this internship, I think I never explained it well enough so that others could understand. Let me give it a try here.
debci is short for “Debian Continuous Integration”, so I’ll start with a short definition of what “Continuous Integration” is then!
Continuous Integration (CI)
Since there should be quite some articles talking about this topic, here is a quick explanation that I found on Microsoft Azure (link):
Continuous Integration (CI) is the process of automating the build and testing of code every time a team member commits changes to version control.
A scenario would be whenever I push code to Debian Salsa Gitlab, it automatically runs the tests we have written in our code. This is to make sure that the new code changes doesn’t break the stuff that used to work.
The debci Project
Before Debian puts out a new release, all of the packages that have tests written in them need to be tested. debci is a platform for testing packages and provides a UI to see if they pass or not. The goal is to make sure that the packages will pass their tests before a major Debian release. For example, when the
ruby-defaults package is updated, we not only want to test
ruby-defaults but also all the packages that depend on it. In short, debci helps make sure the packages are working correctly.
For my internship, I am working on improving the user experience through the UI of the debci site. The most major task is to let developers easily test their packages with packages in different suites and architectures.
The terms that keep popping up in debci are:
There are three obvious suites on the debci site right now, namely unstable, testing and stable. There is also an experimental suite that a user can test their packages upon. And architecture is like amd64 or arm64.
The life of a package is something like this:
- When a package is updated/added, it goes into unstable
- After it has stayed 2-10 days in unstable without any big issues, it moves into testing
- It becomes stable after a release
Let’s say, a user wants to test the
ruby-defaults package in unstable on amd64 along with a package
C from experimental. Here package
C would be a pin-package, which means the package the user wants to test along with. Last but not least, trigger is just the name of the test job, one can choose to use it or not.
Currently, there is an API that you make this request with
curl or something similar, but it’s not very friendly since not everyone is familiar with how the request should look like. Therefore, not a lot of people are willing to use it and I have also seen requests for an improvement on this in the #debci channel. An easy to use UI might be the solution to make requesting these tests easier. Knowing what I am working on is useful for others is an important key to keep myself motivated.
The debci Community
The debci community is very small but active. The people that are directly involved are my mentors: terceiro and elbrus. Sometimes people drop by the IRC channel to ask questions, but basically that’s it. This works pretty good for me, because I’m usually not at ease and will keep a low profile if the community gets too large.
I’m not familiar with the whole Debian community, but I have also been hanging around the #debian-outreach channel. It felt warm to know that someone realized there was an intern from Taiwan for this round of Outreachy. As far as I have experienced, everyone I have chatted with were nice and eager to share which Debian-related communities were close to me.
Week 5: Modularizing & Testing
This week I worked on adding tests and tried pulling out the authentication code to make the code a bit more DRY.
- Learned how to setup tests in Ruby
- Came up with test cases
- Learned more about how classes work in Ruby
- Separated the authentication code
And… probably also writing this blog post! I found that blogging takes up more time than I thought it should.