debian-mirror-gitlab/doc/development/workhorse/index.md

stage	group	info
Create	Source Code	To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments

GitLab Workhorse

GitLab Workhorse is a smart reverse proxy for GitLab. It handles "large" HTTP requests such as file downloads, file uploads, Git push/pull and Git archive downloads.

Workhorse itself is not a feature, but there are several features in GitLab that would not work efficiently without Workhorse.

The canonical source for Workhorse is gitlab-org/gitlab/workhorse.

Learning Resources

• Workhorse documentation (this page)
• GitLab Workhorse Deep Dive: Dependency Proxy video
• How Dependency Proxy via Workhorse works
• Workhorse overview for the Dependency Proxy
• Workhorse architecture discussion

Install Workhorse

To install GitLab Workhorse you need Go 1.18 or newer and GNU Make.

To install into /usr/local/bin run make install.

make install

To install into /foo/bin set the PREFIX variable.

make install PREFIX=/foo

On some operating systems, such as FreeBSD, you may have to use gmake instead of make.

NOTE: Some features depends on build tags, make sure to check Workhorse configuration to enable them.

Run time dependencies

Workhorse uses ExifTool for removing EXIF data (which may contain sensitive information) from uploaded images. If you installed GitLab:

• Using the Omnibus package, you're all set. NOTE that if you are using CentOS Minimal, you may need to install perl package: yum install perl

• From source, make sure exiftool is installed:

  # Debian/Ubuntu
  sudo apt-get install libimage-exiftool-perl
  
  # RHEL/CentOS
  sudo yum install perl-Image-ExifTool
  

Testing your code

Run the tests with:

make clean test

Each feature in GitLab Workhorse should have an integration test that verifies that the feature 'kicks in' on the right requests and leaves other requests unaffected. It is better to also have package-level tests for specific behavior but the high-level integration tests should have the first priority during development.

It is OK if a feature is only covered by integration tests.