User Tools

Site Tools


ochorocho_contribute_to_gitlab

This is an old revision of the document!


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 enbale/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.

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:

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.

Summary

  1. Read the docs … read it again
  2. Make sure people understand what feature you are developing and why you did it this way
  3. Do not intend 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
  4. 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!
  5. Stand your ground! Don't let others make decisions. Take it as a hint and discuss it and adapt your idea/code
  6. Make small MRs - sometimes your first MR is just a single line of code e.g. composer: 6 in the packages.rb
  7. We are all humans. Everyone is trying his/her best.
ochorocho_contribute_to_gitlab.1590230531.txt.gz · Last modified: 2020/05/23 12:42 by admin