User Tools

Site Tools


ochorocho_contribute_to_gitlab

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
ochorocho_contribute_to_gitlab [2020/05/23 12:18] adminochorocho_contribute_to_gitlab [2020/07/03 11:23] (current) – [How i started] admin
Line 11: Line 11:
 This is what i came up with ... 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 +As simple GUI to view available composer packages on a single page with the option to enable/disable it for the Composer Registry 
  
 {{ ::first-shot-gitlab-composer-packages.png?1000 |}} {{ ::first-shot-gitlab-composer-packages.png?1000 |}}
Line 25: Line 25:
 At the beginning i was not aware of all the tools Gitlab offers for development and to maintain code quality. Starting with [[https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/master/doc/set-up-gdk.md|GDK]] which allowed me to get started very quickly and Rubocop to make sure code quality is as expected. At the beginning i was not aware of all the tools Gitlab offers for development and to maintain code quality. Starting with [[https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/master/doc/set-up-gdk.md|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. +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.
- +
-"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 ===== ===== Feedback kicks in or the stage where things go totally wrong =====
  
Line 49: Line 47:
 This ended up in 3 Merge Requests: This ended up in 3 Merge Requests:
  
-  * [[https://gitlab.com/gitlab-org/gitlab/-/merge_requests/17417|Add composer packages feature]] +  * [[https://gitlab.com/gitlab-org/gitlab/-/merge_requests/17417|Add composer packages feature]] - obsolete due to rewrite 
-  * [[https://gitlab.com/gitlab-org/gitlab/-/merge_requests/9306|Add GUI changes to show composer repository paths and copy button]]+  * [[https://gitlab.com/gitlab-org/gitlab/-/merge_requests/9306|Add GUI changes to show composer repository paths and copy button]] - Closed due to move to VueJS after a couple of month
   * [[https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18054|Add composer packages docs]]   * [[https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18054|Add composer packages docs]]
 +
 +And a docker container to build a single composer package https://github.com/ochorocho/gitlab-composer
  
 ===== The reviewer story ===== ===== The reviewer story =====
Line 62: Line 62:
  
 We made tremendous improvements. Code and performance wise. We made tremendous improvements. Code and performance wise.
 +
 +Never had that problem for GUI and Docs MR. 
  
 ===== The social part ===== ===== The social part =====
Line 68: Line 70:
  
 While working on that feature i met people that were really friendly and supportive. 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 [[https://gitlab.com/groups/gitlab-org/-/milestones/47|Gitlab 13.1]]
 +
 +Thanks to Mayra, Ray and of course GG for getting this out the door.
 +
  
 ===== Summary ===== ===== Summary =====
  
-  - Read the docs ... read it again+  - Read the [[https://docs.gitlab.com/ce/development/|docs]] ... read it again
   - Make sure people understand what feature you are developing and why you did it this way   - Make sure people understand what feature you are developing and why you did it this way
-  - 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+  - 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!   - 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   - 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: 6'' in the [[https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/models/packages/package.rb#L38|packages.rb]]
   - We are all humans. Everyone is trying his/her best.   - We are all humans. Everyone is trying his/her best.
  
ochorocho_contribute_to_gitlab.1590229097.txt.gz · Last modified: 2020/05/23 12:18 by admin