GitLab - fixing problems in open source software can make you feel better
Von Michael Telgkamp, veröffentlicht am 12.04.2021
We use GitLab as our source code managing tool at mindscreen. We use the Community Edition (ce) and host it on our own. After the simple "relates to" relationship for issues moved to GitLab Free in 13.4, I found an issue with that feature and reported it as my first GitLab issue: Related issues / Linked issues stylesheet problem on October 29th 2020. It was a visual glitch, but I was hoping for it will being fixed, as it seemed not to be very complicated to fix and I already found a missing style.
There was a review some days later and it was attached the severity 4 - which is the lowest. So I was not expecting it will be fixed quickly.
On November 4th 2020 there was a comment with a patch. It suggested to add the required styles as HTML in the footer message. I was able to apply this and thus circumvent the issue for our instance, but adding a stylesheet in the footer and did not feel like a solution for the long run.
Some days later, there was also a comment the issue had been reported by someone else earlier in #258678: Rendering issue with the add related issues form on GitLab Core.
As the workaround worked fine, I did not have this issue in mind, until the fix caused a minor glitch and I had to adjust the fix on April 7th 2021. After I saw the label "Accepting merge requests" on the second Issue, I considered to clone the GitLab code and have a look if I really could see how to fix this issue.
It turned out to be a quite straight forward fix. Having the information from the comment with the patch I was able to find the corresponding code. It was already available for the Enterprise edition (ee) Version of GitLab, and just needed to move the required parts from the ee version of the stylesheet to the ce version of the stylesheet. So I created a fork, made the changes, pushed them to the fork and opened a Merge Request to get them into core. Although I did not manage to have a pipeline run without errors in the first commit, the contribution documentation and the output of the CI Pipelines enabled me to fix this and have the pipeline run without errors.
The rest of the process was out of my hands and I expected it to take some time until someone will have a look. It actually turned out to be an astonishing quick response, as there was a first positive reaction on the same day and a first positive review on the next day. As that was on a Friday, I was waiting what will happen on Monday and on the time I started working the Merge Request was already merged into core.
In total my first contribution to GitLab was a very positive experience with three friendly and very positive reviews. It was a minor issue, but knowing I fixed it and getting the positive feedback in the review process made me feel better!