This section of the configuration file is mainly used to define the global settings for the whole GitLab application.

The first settings you will encounter are mainly for the web server component (Unicorn). You can specify which FQDN to use for the hostname, the port on which to listen to, and whether to use HTTPS:

    host: localhost
     port: 80 
     https: false

You can set the port to 443 and HTTPS to true if you want to use HTTPS. If you have a different ssh_host in your setup, you can specify it as well (If you want Git-SSH to run on the same server, that you don't need to specify this):

    ssh_host: ssh.host_example.com

Furthermore, if you want to use relative URLs (/mygitlab/ for instance):

  relative_url_root: /gitlab

You can also change the option regarding which OS-user to use for running the web server processes:

user: git

The next setting is about dates and times, and you can specify the timezone to be used throughout the entire application:

 time_zone: 'UTC'

The next bundle of settings handles email. You can disable GitLab's use of email entirely or specify who the sender and the subject, among other things:

email_enabled: true
 email_from: [email protected]
 email_display_name: GitLab
 email_reply_to: [email protected]
 email_subject_suffix: ''

The next setting determines whether new users can create groups (be careful, as existing users retain this privilege).

default_can_create_group: false

If you want old users to be also stripped of this privilege, one way to do it is to use the Rails console:

irb(main):012:0> @users.each do |u|
 irb(main):013:1*  u.can_create_group= false
 irb(main):014:1> u.save
 irb(main):015:1> end

The next option allows you the option to change your username. This is generally not recommended if you use another system such as Lightweight Directory Access Protocol (LDAP) for account management:

username_changing_enabled: false

The next set of options determines the style to be used for GitLab; I suggest you try them all (1-10):

 # default_theme: 1 # default: 1

A nice feature that can automate your development workflow very efficiently is the automatic closing of issues by issuing a commit to the default project branch. You can use the following pattern to make the automation work. If it matches, it will be closed. The pattern is quite complicated, so we will use the code provided:

issue_closing_pattern: '((?:[Cc]los(?:e[sd]?|ing)|[Ff]ix(?:e[sd]|ing)?|[Rr]esolv(?:e[sd]?|ing)|[Ii]mplement(?:s|ed|ing)?)(:?) +(?:(?:issues? +)?%{issue_ref}(?:(?:, *| +and +)?)|([A-Z][A-Z0-9_]+-d+))+)'

We could, for example, use the following commit message:

 Fix #122 and Closes groupx/bestproject#1000.
 Also  important for #10 and fixes #11, #229 and #188
 and https://gitlab.example.com/group/mything/issues/9999.

In the preceding example, #122, #1000, #11, #229, #188, and #9999 will be automatically closed. Only #10 will not be touched, because it does not match the pattern.

In GitLab, in each project you have some default capabilities, such as the possibility to create issues or a wiki in the project space. There is an option to disable or enable them by default:

default_projects_features:
     issues: true
     merge_requests: true
     wiki: true
     snippets: true
     builds: true
     container_registry: true

The CI/CD component of GitLab relies heavily on webhooks as its primary eventing mechanism over network boundaries. On slow networks, you may want to increase the timeout value of them to make them try harder:

webhook_timeout: 10

You can download the contents of a project, which are combined in a ZIP file. This creation of a ZIP file needs some temporary disk space, which you can define here, the repository downloads directory (relative path to the Rails directory):

 repository_downloads_path: shared/cache/archive/

GitLab can also utilize an email client, which can get mail from an IMAP server, and parse the mail contents for issues and merge request IDs. If you set this up correctly, you can allow users to reply to notification emails, and the result will be added to the issue or the merge request. The first part is where you enable or disable the function:

 incoming_email:
   enabled: false

The second part is where you define the incoming email address that is used and what part of it is variable (every merge-request or issue number is a variable):

  address: "gitlab-incoming+%{key}@gmail.com"

The other settings mainly concern the IMAP server that is used along with the credentials and connection settings:

  user: "[email protected]"
   password: "[REDACTED]"
   host: "imap.gmail.com"
   port: 993
   ssl: true
   start_tls: false
 mailbox: "inbox"
  idle_timeout: 60

These settings together enable incoming email for your GitLab instance.

This concludes the section in the configuration file that covers some general settings. The next section is about storing different kinds of files.