Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Developer Cheatsheet

  1. You are here:
  2. Engineering
  3. Development Department
  4. Dev Sub-department
  5. Create Stage
  6. Create:Editor Team
  7. Developer Cheatsheet

Useful Commands

general

gitlab-org/gitlab

Running QA Specs

See https://gitlab.com/gitlab-org/gitlab/tree/master/qa#how-can-i-use-it for more details.

To run the QA specs in RubyMine, use a custom rspec runner configuration (right click on the arrow next to the example in the gutter), and set the qa/bin/rubymine script as the custom RSpec runner script, and the working directory as qa.

See more detailed instructions for this process here: https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/end_to_end_test_configuration.md#starting-tests-using-the-rubymine-gutter

gitlab-com/www-gitlab-com

Tips and Tricks

GDK Tips

Running Web IDE Terminal in GDK

GDK Debugging

Log Debugging

RubyMine Debugging

Debugging rails-web
Note on Rails Puma binding

By default, the Rails puma configuration template which GitLab uses binds to a socket, instead of a TCP port.

This MR added support for configuring the GDK to bind Rails puma to a TCP socket, and added support for Workhorse to use TCP ports instead of sockets.

See the architecture documentation around components for more details on how GitLab Workhorse and Puma work together.

Why is all of this important?

Because unfortunately, because of this RubyMine bug (https://youtrack.jetbrains.com/issue/RUBY-27404), it is not possible to use the default RubyMine Rails Run Configuration with a puma configuration which uses a socket binding. (NOTE: If you want this fixed, please go to the issue and thumbs-up to vote for it!)

So, you have two choices to work around this:

  1. Set up a RubyMine "Ruby" Run Configuration to directly run puma using the default socket binding. Even though this is a slightly more complex config in RubyMine, it is recommended, because it will still continue working even if you reinstall your GDK and lose the overridden config to bind puma to a TCP port.
  2. Configure the GDK to bind puma to a TCP port, and set up a RubyMine "Rails" Run Configuration for that port. This may also be useful for other debugging scenarios, like being able to use Wireshark to debug TCP traffic.

Note that you COULD just not worry about any of this, and run a normal RubyMine "Rails" Run Configuration without changing the GDK config, and directly connect to the port it uses (by default 3000). However, this means that you won't be connecting and proxying through the GitLab Workhorse according to the standard component architecture, and some features may be slower, work differently, or not work at all. So, it's safer to go ahead and do one of these two suggested options to use a standard configuration running puma behind the Workhorse proxy.

The following two sections explain how to do those two options.

  1. Make sure you have done gdk stop rails-web before each debugging session (and gdk start rails-web when you are done debugging)
  2. Set up a Ruby (NOT Rails) Run/Debug config like this in RubyMine:
    • Name: Development: gitlab-puma (use if gdk.yml gitlab rails address IS NOT overridden to use TCP port)
    • Ruby Script (Note: This is actually from the gitlab-puma gem): /Users/YOUR_USER/.asdf/installs/ruby/RUBY_VERSION/bin/puma
    • Script Arguments: --config /Users/YOUR_USER/PATH_TO/gitlab-development-kit/gitlab/config/puma.rb --environment development
    • Working Directory: /Users/YOUR_USER/PATH_TO/gitlab-development-kit/gitlab/
    • Environment Variables (Note: these are taken from the current GDK Procfile, they may become outdated): RAILS_ENV=development;RAILS_RELATIVE_URL_ROOT=/;ACTION_CABLE_IN_APP=true;ACTION_CABLE_WORKER_POOL_SIZE=4
  3. Start the config in Run or Debug.
Setting up a RubyMine "Rails" Run Configuration with puma overridden to use TCP address binding
  1. In your gitlab-development-kit/gdk.yml, add the following. You can use any port, and the hostname should be whatever you normally use - localhost, or gdk.test if you have that hostname set up. 
     gitlab:
   rails:
     address: gdk.test:3001
  2. gdk reconfigure to apply the settings to the bind entry in gitlab-development-kit/gitlab/config/puma.rb
  3. Make sure you have done gdk stop rails-web before each debugging session (and gdk start rails-web when you are done debugging)
  4. Set up a Rails Run/Debug config like this in RubyMine:
    • Name (optional): Development: gitlab (use if gdk.yml gitlab rails address IS overridden to use TCP port)
    • IP Address: 0.0.0.0
    • Port: 3001 (or whatever you put in gdk.yml)
    • Environment Variables (Note: these are taken from the current GDK Procfile, they may become outdated): RAILS_ENV=development;RAILS_RELATIVE_URL_ROOT=/;ACTION_CABLE_IN_APP=true;ACTION_CABLE_WORKER_POOL_SIZE=4
  5. Start the config in Run or Debug.
Debugging rails-background-jobs

To debug services run as background jobs, you will need to set up debugging for rails-background-jobs, in addition to the rails-web debugger. The setup is similar, although you're connecting to the sidekiq process instead of puma.

  1. Make sure you have done gdk stop rails-background-jobs before each debugging session (and gdk start rails-background-jobs when you are done debugging)
  2. Set up a Ruby (NOT Rails) Run/Debug config like this in RubyMine:
    • Name: Development: gitlab-sidekiq
    • Ruby Script: /Users/YOUR_USER/.asdf/installs/ruby/RUBY_VERSION/bin/sidekiq
    • Working Directory /Users/YOUR_USER/PATH_TO/gitlab-development-kit/gitlab/
    • Environment Variables (Note: these are taken from the current GDK Procfile, they may become outdated): SIDEKIQ_VERBOSE=false;SIDEKIQ_QUEUES=default,mailers,email_receiver,hashed_storage:hashed_storage_migrator,hashed_storage:hashed_storage_project_migrate,hashed_storage:hashed_storage_project_rollback,hashed_storage:hashed_storage_rollbacker,project_import_schedule,service_desk_email_receiver;BUNDLE_GEMFILE=/Users/YOUR_USER/PATH_TO/gitlab-development-kit/gitlab/Gemfile;SIDEKIQ_WORKERS=1;ENABLE_BOOTSNAP=true;RAILS_ENV=development;RAILS_RELATIVE_URL_ROOT=/;GITALY_DISABLE_REQUEST_LIMITS=false

Git Tips

Rebasing

Git References

Interactive Git Learning Tools

Squashing down a branch which has had master merged into it

When a branch has followed a merge instead of a rebase workflow, it can get very confusing to know what is going on, and you want to just squash it down to a single commit. But, you can't just do a regular interactive rebase relative to master if the branch has had master merged into it. Here's what you have to do instead.

Note there may be more efficient ways of doing this, suggestions are welcome. Also note that sometimes this doesn't work, you'll end up with almost all the changes from the branch uncommitted after step 5 - not sure why :(

Assuming branch is named branch and upstream is named master:

  1. Do a log of all the commits on the branch: git log master..branch --oneline
  2. Find the last (latest) commit on the branch. It will be the top one, assume it is 123456.
  3. Find the first (earliest) commit on the branch. It will be the bottom one, assume it is abcdef.
  4. Reset hard to the first commit: git reset --hard abcdef
  5. merge --squash the last commit: git merge --squash 123456
  6. There may be extra changes from the master commits that you don't want. Get rid of them with:
    1. git restore --staged .
    2. git checkout .
    3. git clean -df

Working with Issues/MRs

Settings && Navigation Development

Currently our sidebar implementation lives in:

When you need to edit, delete or insert a new sidebar field, you will be working inside these files. The base menu class lives in lib/sidebars/menu.rb and all other menu items inherit it. If you need different behavior for a menu item, you can override this base class in your implementation. More information about the full implementation is available.

New habits

Though the contributor and development docs are the single source of truth, there are some additional habits that may be worth developing when you're new to the code contribution process.

Depending on your existing habits and git practices the habits below may help mitigate pain during code submissions.

Dealing with Broken Master

Browser Testing

About testing:

Some frontendmasters workshops related to testing that I want to take after the web security workshop:

Open in Web IDE View source