Awesome! You're about to become a GitLab developer! Make sure you've checked out our handbook beforehand, so you get a feeling of how we work at GitLab. Below you'll find everything you need to start developing. If something is missing, add it (as goes with everything at GitLab)!
We have multiple GitLab environments.
On those instances, please enable the performance bar by pressing p then b (even on production.)
Then, read how to use and enable the production Canary on GitLab.com.
To start development, follow the instructions for the GitLab Development Kit.
GitLab consists of many subprojects. A curated list of GitLab Repositories can be found at the GitLab Engineering Projects page.
Almost all repositories are available on both GitLab.com and dev.gitlab.org. We also mirror to dev.gitlab.org for availability reasons and GitHub for historical reasons.
All issues should be filed on GitLab.com.
For everything related to infrastructure, check out the Infrastructure handbook. In particular production architecture might be useful for onboarding.
If you need a VPS for any reason, it's probably easiest to set one up at DigitalOcean. Ask another developer for access.
Please see the engineering workflow document in the handbook and read the developer documentation.
Read the developer security documentation prior to working on a security issue.
One of GitLab's strengths is its high quality of software. To achieve this we've introduced some requirements to all source code that is contributed. All requirements are mentioned in the Contribution guide. Make sure you read and follow it.
GitLab can be installed through an Omnibus package or from source on different Linux distributions and macOS. In order to maintain portability, we need to avoid adding extra dependencies and use of exotic database extensions. Every time you choose between changes in the application code or adding new dependencies, you should give priority to the first because this is easier to maintain and set up. If you still need to bring new dependencies to GitLab, ask another developer or the CTO for advice.
In GitLab all code should go through a review process before it can be merged. Make sure you submit a merge request for any changes you've made. When the merge request is ready, it should be assigned to someone else on the team. This person is then responsible for reviewing your code and merging it. Optionally, you can request another developer to help or review by writing a comment. If a merge request is not assigned, it will probably be ignored and create unnecessary delays.
Don't work on one task for multiple days before submitting a merge request. Even the biggest task can be split into smaller tasks. Try to submit a merge request for each part of the functionality. This means that we expect multiple merge requests per week from you. Smaller merge requests are more likely to receive good feedback and will get merged sooner.
Unless the change is very minor, or is fixing a bug that was introduced in the
same version, create a changelog entry using the
Changelog Git commit trailer.
Do not include your name in the entry as we only do that to give recognition to
volunteer contributors.
GitLab EE requires a license key to be used.
Team members should open an issue
using the GitLab_Team_Member_License_request template. In the issue, request for a license that is valid for a year, and provide "Developer on-boarding"
as the reason for a longer expiration.
Wider community members should contact the Contributor Success Team.
Learn more about working with licensing and subscriptions internally.
When publishing gems for GitLab, you should:
gitlab-qa RubyGems.org user.
The user credentials can be found in the 1password Engineering vault.Adding it to the list of Gem Owners on RubyGems.org. You can also do this from a command line with the gem tool. For example, run this command to make the gitlab-qa user a co-owner:
$ gem owner <gem_name> --add gitlab-qa
Gem projects should use the shared CI/CD config
to release and publish new gem versions by adding the following to their .gitlab-ci.yml:
include:
- project: 'gitlab-org/quality/pipeline-common'
file: '/ci/gem-release.yml'
Note that this will include access token configuration inherited from the gitlab-org group, which will
be used to upload the gem package to rubygems.org.
Make sure to create a v0.0.0 tag if you don't already have any SemVer tag so
that the auto-release can compute the diff when releasing the actual first version of the gem.
This job will handle building and publishing the gem, as well as creating the tag, release and populating its release notes by
using the Generate changelog data API endpoint.
For instructions for when and how to generate a changelog entry file, see the dedicated Changelog entries page.
To be consistent with the GitLab project,
Gem projects could also define a changelog YAML configuration file at .gitlab/changelog_config.yml with the same content
as in the gitlab-styles gem.
To ease the release process, you could also create a .gitlab/merge_request_templates/Release.md MR template with the same content
as in the gitlab-styles gem
(make sure to replace gitlab-styles with the actual gem name).