Table of Contents
How to contribute to Gitlab ... or not
How i started
Back in dec 2018 i was not happy about the way satis was used to build composer packages in our company. I felt like this is to complex for what it was doing and took to long to build (~3 minutes for 50 packages) on the Gitlab Runner.
So i checked gitlab.com for any existing solution to my problem. Finally found a feature proposal.
So i decided to give it a shot. After making sure Gitlab will accept Merge Requests for this feature. Well, how long could it take if you have already half the job done on the first commit? At least i felt like i made big progress.
This is what i came up with …
As simple GUI to view available composer packages on a single page with the option to enable/disable it for the Composer Registry
… and the required JSON for Composer to read packages
I really loved this idea for it's simplicity. No Runner required, no build process. Simply link the package in composers JSON file to Gitlabs “Download Code/Tag” feature. No rocket science here.
Discover Gitlab
At the beginning i was not aware of all the tools Gitlab offers for development and to maintain code quality. Starting with GDK which allowed me to get started very quickly and Rubocop to make sure code quality is as expected.
In general, Gitlab will scan each and every corner of your code and will tell you what you did potentially wrong. “Potentially wrong” ?! Well, in some cases you have to ignore Rubocop checks. Best is to talk to your reviewer if one exists.
Pipelines are amazing! Look at the jobs it will tell you all you need to know to write code for Gitlab.
Feedback kicks in or the stage where things go totally wrong
Got feedback from Gitlab:
@ochorocho please take a look at maven and npm packages implementation in GitLab for idea of what we are expecting:
Ok, so i followed along the code and tried to make it work the way maven and all the other packages work. At that time there was no code in Gitlabs CE repository. So i started over and used Gitlabs EE repository and requested an EE License which was really easy. Just sent a message to Ray on Gitter.
So in my mind i had to implement following features:
- Use a runner to build and upload the package to Gitlab
- Create/extend packages template for Composer
- Create JSON file containing only the packages a user is allowed to view
- Add tests for API endpoints and features
- Add docs
This ended up in 3 Merge Requests:
- Add composer packages feature - obsolete due to rewrite
- Add GUI changes to show composer repository paths and copy button - Closed due to move to VueJS after a couple of month
And a docker container to build a single composer package https://github.com/ochorocho/gitlab-composer
The reviewer story
While working on this feature there was no existing Gitlab Packages Team. So i created my MRs and requested a reviewer. After a few iterations of review and improve code the reviewer did not respond to my messages anymore. No idea why. He did not complain about my ideas. He just disappeared.
After waiting a bit i pinged the community manager. He asked someone else to review my MR which worked out even worse. A few comments and he was gone. Again, no idea what happend.
Finally in sep 2019 a new (3rd !!!) reviewer was involved. Things got a lot better. GG, reviewer and member of the packages team started to get familiar with composer and how it works.
We made tremendous improvements. Code and performance wise.
Never had that problem for GUI and Docs MR.
The social part
Australia was on the list for 2019 holiday. So i asked GG if he is up for a few drinks. So i travelled from Sydney to Melbourne to catch up for a few drinks. Awesome! 
While working on that feature i met people that were really friendly and supportive.
Back to beginning
I felt like we're sooooo close to get this thing merged. To be honest i thought this already for a few month. But this time i was sure. What could possibly go wrong? I had someone to review my code. Reduced the code size by ~30%, the runner built a package in 10 seconds.
I thought i was cool at that point. Even though it was not working like packagist.com. But that was never my intention.
In the end GG was not happy about the solution building a package using the runner when the required files are already in Gitlab via the “Download Code/Tag” feature. So we agreed on starting from scratch and leave out the runner part.
My initial idea was correct, but at that time there was no one paying attention to that detail.
After all this is stopped working on Composer Packages for Gitlab. After 14 month of development and ~200 hours spent learning rails, get used to Gitlab development process and building the Composer Packages feature i was frustrated to a hellish extent.
Luckily
In feb 2020 GG started to write proper feature issues to make sure things are done right. While i was busy living life GG rewrote the entire thing and it will hopefully be available in Gitlab 13.1
Thanks to Mayra, Ray and of course GG for getting this out the door.
Summary
- Read the docs … read it again
- Make sure people understand what feature you are developing and why you did it this way
- Do not expect that reviewers are experts in that field you are developing a feature for. Make them experts by providing docs and detailed answers to their questions
- Be a little pushy when your MR does not attract their attention by writing a message on Gitter to the community manager. Pushy does not mean being impolite!
- Stand your ground! Don't let others make decisions. Take it as a hint and discuss it and adapt your idea/code
- Make small MRs - sometimes your first MR is just a single line of code e.g.
composer: 6in the packages.rb - We are all humans. Everyone is trying his/her best.