2020-10-29 17:08:54 -04:00
---
stage: none
group: unassigned
2020-11-26 01:09:20 -05:00
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
2020-10-29 17:08:54 -04:00
---
2018-03-23 12:29:55 -04:00
# GitLab.com settings
2020-11-19 22:09:15 -05:00
This page contains information about the settings that are used on
2019-07-08 19:14:29 -04:00
[GitLab.com ](https://about.gitlab.com/pricing/ ).
2018-03-23 12:29:55 -04:00
## SSH host keys fingerprints
2020-04-08 20:10:12 -04:00
Below are the fingerprints for GitLab.com's SSH host keys. The first time you connect
2020-11-19 22:09:15 -05:00
to a GitLab.com repository, one of these keys is displayed in the output.
2018-03-23 12:29:55 -04:00
2020-04-08 20:10:12 -04:00
| Algorithm | MD5 (deprecated) | SHA256 |
2018-03-23 12:29:55 -04:00
| --------- | --- | ------- |
2020-04-08 20:10:12 -04:00
| DSA (deprecated) | `7a:47:81:3a:ee:89:89:64:33:ca:44:52:3d:30:d4:87` | `p8vZBUOR0XQz6sYiaWSMLmh0t9i8srqYKool/Xfdfqw` |
2018-03-23 12:29:55 -04:00
| ECDSA | `f1:d0:fb:46:73:7a:70:92:5a:ab:5d:ef:43:e2:1c:35` | `HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw` |
| ED25519 | `2e:65:6a:c8:cf:bf:b2:8b:9a:bd:6d:9f:11:5c:12:16` | `eUXGGm1YGsMAS7vkcx6JOJdOGHPem5gQp4taiCfCLB8` |
| RSA | `b6:03:0e:39:97:9e:d0:e7:24:ce:a3:77:3e:01:42:09` | `ROQFvPThGrW4RuWLoL9tq9I9zJ42fK4XywyRtbOz/EQ` |
2019-12-04 10:11:23 -05:00
## SSH `known_hosts` entries
Add the following to `.ssh/known_hosts` to skip manual fingerprint
confirmation in SSH:
2020-01-30 01:08:49 -05:00
```plaintext
2019-12-04 10:11:23 -05:00
gitlab.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAfuCHKVTjquxvt6CM6tdG4SLp1Btn/nOeHHE5UOzRdf
gitlab.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCsj2bNKTBSpIYDEGk9KxsGh3mySTRgMtXL583qmBpzeQ+jqCMRgBqB98u3z++J1sKlXHWfM9dyhSevkMwSbhoR8XIq/U0tCNyokEi/ueaBMCvbcTHhO7FcwzY92WK4Yt0aGROY5qX2UKSeOvuP4D6TPqKF1onrSzH9bx9XUf2lEdWT/ia1NEKjunUqu1xOB/StKDHMoX4/OKyIzuS0q/T1zOATthvasJFoPrAjkohTyaDUz2LN5JoH839hViyEG82yB+MjcFV5MU3N1l1QL3cVUCh93xSaua1N85qivl+siMkPGbO5xR/En4iEY6K2XPASUEMaieWVNTRCtJ4S8H+9
gitlab.com ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBFSMqzJeV9rUzU4kWitGjeR4PWSa29SPqJ1fVkhtj3Hw9xjLVXVYrU9QlYWrOLXBpQ6KWjbjTDTdDkoohFzgbEY=
```
2018-03-23 12:29:55 -04:00
## Mail configuration
2020-04-21 11:21:10 -04:00
GitLab.com sends emails from the `mg.gitlab.com` domain via [Mailgun ](https://www.mailgun.com/ ) and has
2020-08-10 14:09:54 -04:00
its own dedicated IP address (`192.237.158.143`).
2020-07-17 17:09:23 -04:00
2020-12-04 16:09:29 -05:00
NOTE:
2020-07-17 17:09:23 -04:00
The IP address for `mg.gitlab.com` is subject to change at any time.
2018-03-23 12:29:55 -04:00
2020-05-29 08:08:19 -04:00
## Backups
[See our backup strategy ](https://about.gitlab.com/handbook/engineering/infrastructure/production/#backups ).
2020-09-28 11:09:44 -04:00
There are several ways to perform backups of your content on GitLab.com.
Projects can be backed up in their entirety by exporting them either [through the UI ](../project/settings/import_export.md ) or [API ](../../api/project_import_export.md#schedule-an-export ), the latter of which can be used to programmatically upload exports to a storage platform such as AWS S3.
With exports, be sure to take note of [what is and is not ](../project/settings/import_export.md#exported-contents ), included in a project export.
2020-11-19 22:09:15 -05:00
Since GitLab is built on Git, you can back up **just** the repository of a project by [cloning ](../../gitlab-basics/start-using-git.md#clone-a-repository ) it to another machine. Similarly, if you need to back up just the wiki of a repository it can also be cloned and all files uploaded to that wiki are included [if they were uploaded after 2020-08-22 ](../project/wiki/index.md#creating-a-new-wiki-page ).
2020-09-28 11:09:44 -04:00
2018-03-23 12:29:55 -04:00
## Alternative SSH port
2020-04-21 11:21:10 -04:00
GitLab.com can be reached via a [different SSH port ](https://about.gitlab.com/blog/2016/02/18/gitlab-dot-com-now-supports-an-alternate-git-plus-ssh-port/ ) for `git+ssh` .
2018-03-23 12:29:55 -04:00
| Setting | Value |
| --------- | ------------------- |
| `Hostname` | `altssh.gitlab.com` |
| `Port` | `443` |
An example `~/.ssh/config` is the following:
2020-01-30 01:08:49 -05:00
```plaintext
2018-03-23 12:29:55 -04:00
Host gitlab.com
Hostname altssh.gitlab.com
User git
Port 443
PreferredAuthentications publickey
IdentityFile ~/.ssh/gitlab
```
## GitLab Pages
2020-03-22 23:09:21 -04:00
Below are the settings for [GitLab Pages ](https://about.gitlab.com/stages-devops-lifecycle/pages/ ).
2018-03-23 12:29:55 -04:00
2019-08-22 10:45:53 -04:00
| Setting | GitLab.com | Default |
| --------------------------- | ---------------- | ------------- |
| Domain name | `gitlab.io` | - |
| IP address | `35.185.44.232` | - |
| Custom domains support | yes | no |
| TLS certificates support | yes | no |
2020-09-03 14:08:29 -04:00
| Maximum size (compressed) | 1G | 100M |
2019-08-22 10:45:53 -04:00
2020-12-04 16:09:29 -05:00
NOTE:
2018-03-23 12:29:55 -04:00
The maximum size of your Pages site is regulated by the artifacts maximum size
2019-03-10 21:47:01 -04:00
which is part of [GitLab CI/CD ](#gitlab-cicd ).
2018-03-23 12:29:55 -04:00
## GitLab CI/CD
Below are the current settings regarding [GitLab CI/CD ](../../ci/README.md ).
2020-10-23 02:08:51 -04:00
Any settings or feature limits not listed here are using the defaults listed in the related documentation.
2018-03-23 12:29:55 -04:00
| Setting | GitLab.com | Default |
| ----------- | ----------------- | ------------- |
2020-09-03 14:08:29 -04:00
| Artifacts maximum size (compressed) | 1G | 100M |
2020-06-17 23:08:26 -04:00
| Artifacts [expiry time ](../../ci/yaml/README.md#artifactsexpire_in ) | From June 22, 2020, deleted after 30 days unless otherwise specified (artifacts created before that date have no expiry). | deleted after 30 days unless otherwise specified |
2020-03-13 05:09:23 -04:00
| Scheduled Pipeline Cron | `*/5 * * * *` | `19 * * * *` |
2020-01-20 22:08:37 -05:00
| [Max jobs in active pipelines ](../../administration/instance_limits.md#number-of-jobs-in-active-pipelines ) | `500` for Free tier, unlimited otherwise | Unlimited
2020-07-29 05:09:33 -04:00
| [Max CI/CD subscriptions to a project ](../../administration/instance_limits.md#number-of-cicd-subscriptions-to-a-project ) | `2` | Unlimited |
2020-03-17 14:09:44 -04:00
| [Max pipeline schedules in projects ](../../administration/instance_limits.md#number-of-pipeline-schedules ) | `10` for Free tier, `50` for all paid tiers | Unlimited |
2020-09-07 11:09:04 -04:00
| [Scheduled Job Archival ](../../user/admin_area/settings/continuous_integration.md#archive-jobs ) | 3 months | Never |
2020-10-15 23:08:29 -04:00
| Max test cases per [unit test report ](../../ci/unit_test_reports.md ) | `500_000` | Unlimited |
2018-03-23 12:29:55 -04:00
2020-09-15 17:09:35 -04:00
## Account and limit settings
2018-03-30 06:25:07 -04:00
2020-06-19 08:09:07 -04:00
GitLab.com has the following [account limits ](../admin_area/settings/account_and_limit_settings.md ) enabled. If a setting is not listed, it is set to the default value.
2018-03-30 06:25:07 -04:00
2020-06-19 08:09:07 -04:00
If you are near
or over the repository size limit, you can [reduce your repository size with Git ](../project/repository/reducing_the_repo_size_using_git.md ).
| Setting | GitLab.com | Default |
| ----------- | ----------- | ------------- |
2020-11-13 10:09:24 -05:00
| [Repository size including LFS ](../admin_area/settings/account_and_limit_settings.md ) | 10 GB | Unlimited |
2020-09-15 17:09:35 -04:00
| Maximum import size | 5 GB | 50 MB |
2018-03-30 06:25:07 -04:00
2020-12-04 16:09:29 -05:00
NOTE:
2020-06-19 08:09:07 -04:00
`git push` and GitLab project imports are limited to 5 GB per request through Cloudflare. Git LFS and imports other than a file upload are not affected by this limit.
2020-03-25 20:07:58 -04:00
2019-03-26 11:51:01 -04:00
## IP range
2020-03-16 17:09:21 -04:00
GitLab.com is using the IP range `34.74.90.64/28` for traffic from its Web/API
2020-04-06 02:09:19 -04:00
fleet. This whole range is solely allocated to GitLab. You can expect connections from webhooks or repository mirroring to come
2020-06-17 20:08:35 -04:00
from those IPs and allow them.
2019-03-26 11:51:01 -04:00
2020-06-17 20:08:35 -04:00
GitLab.com is fronted by Cloudflare. For incoming connections to GitLab.com you might need to allow CIDR blocks of Cloudflare ([IPv4](https://www.cloudflare.com/ips-v4) and [IPv6 ](https://www.cloudflare.com/ips-v6 )).
2020-03-26 11:08:16 -04:00
For outgoing connections from CI/CD runners we are not providing static IP addresses.
2020-03-16 17:09:21 -04:00
All our runners are deployed into Google Cloud Platform (GCP) - any IP based
firewall can be configured by looking up all
[IP address ranges or CIDR blocks for GCP ](https://cloud.google.com/compute/docs/faq#where_can_i_find_product_name_short_ip_ranges ).
2019-03-26 11:51:01 -04:00
2020-08-12 11:10:02 -04:00
## Webhooks
2020-02-27 19:09:08 -05:00
A limit of:
- 100 webhooks applies to projects.
- 50 webhooks applies to groups. ** (BRONZE ONLY)**
2020-08-12 11:10:02 -04:00
- Payload is limited to 25MB
2020-02-27 19:09:08 -05:00
2020-09-13 23:09:21 -04:00
## Shared runners
2018-03-23 12:29:55 -04:00
2020-01-20 22:08:37 -05:00
GitLab offers Linux and Windows shared runners hosted on GitLab.com for executing your pipelines.
2020-12-04 16:09:29 -05:00
NOTE:
2020-09-13 23:09:21 -04:00
Shared runners provided by GitLab are **not** configurable. Consider [installing your own runner ](https://docs.gitlab.com/runner/install/ ) if you have specific configuration needs.
2020-05-15 17:08:21 -04:00
2020-09-13 23:09:21 -04:00
### Linux shared runners
2020-01-20 22:08:37 -05:00
2020-12-10 01:09:47 -05:00
Linux shared runners on GitLab.com run in autoscale mode and are powered by Google Cloud Platform.
Autoscaling means reduced queue times to spin up CI/CD jobs, and isolated VMs for each project, thus maximizing security. These shared runners are available for users and customers on GitLab.com.
GitLab offers Gold tier capabilities and included CI/CD minutes per group per month for our [Open Source ](https://about.gitlab.com/solutions/open-source/join/ ), [Education ](https://about.gitlab.com/solutions/education/ ), and [Startups ](https://about.gitlab.com/solutions/startups/ ) programs. For private projects, GitLab offers various [plans ](https://about.gitlab.com/pricing/ ), starting with a Free tier.
2018-03-23 12:29:55 -04:00
2018-09-03 19:08:14 -04:00
All your CI/CD jobs run on [n1-standard-1 instances ](https://cloud.google.com/compute/docs/machine-types ) with 3.75GB of RAM, CoreOS and the latest Docker Engine
2018-04-05 14:20:39 -04:00
installed. Instances provide 1 vCPU and 25GB of HDD disk space. The default
region of the VMs is US East1.
2018-09-03 19:08:14 -04:00
Each instance is used only for one job, this ensures any sensitive data left on the system can't be accessed by other people their CI jobs.
2018-03-23 12:29:55 -04:00
2020-11-19 22:09:15 -05:00
The `gitlab-shared-runners-manager-X.gitlab.com` fleet of runners are dedicated for GitLab projects as well as community forks of them. They use a slightly larger machine type (n1-standard-2) and have a bigger SSD disk size. They don't run untagged jobs and unlike the general fleet of shared runners, the instances are re-used up to 40 times.
2019-12-05 16:07:40 -05:00
2020-09-13 23:09:21 -04:00
Jobs handled by the shared runners on GitLab.com (`shared-runners-manager-X.gitlab.com`),
2020-11-19 22:09:15 -05:00
**time out after 3 hours**, regardless of the timeout configured in a
2020-05-21 23:08:28 -04:00
project. Check the issues [4010 ](https://gitlab.com/gitlab-com/infrastructure/-/issues/4010 ) and [4070 ](https://gitlab.com/gitlab-com/infrastructure/-/issues/4070 ) for the reference.
2018-05-16 02:47:18 -04:00
2020-09-13 23:09:21 -04:00
Below are the shared runners settings.
2018-03-23 12:29:55 -04:00
| Setting | GitLab.com | Default |
| ----------- | ----------------- | ---------- |
2020-04-21 11:21:10 -04:00
| [GitLab Runner ](https://gitlab.com/gitlab-org/gitlab-runner ) | [Runner versions dashboard ](https://dashboards.gitlab.com/d/000000159/ci?from=now-1h&to=now&refresh=5m&orgId=1&panelId=12&fullscreen&theme=light ) | - |
2018-03-23 12:29:55 -04:00
| Executor | `docker+machine` | - |
2018-04-05 14:20:39 -04:00
| Default Docker image | `ruby:2.5` | - |
2020-04-21 11:21:10 -04:00
| `privileged` (run [Docker in Docker ](https://hub.docker.com/_/docker/ )) | `true` | `false` |
2018-03-23 12:29:55 -04:00
2020-04-26 23:09:51 -04:00
#### Pre-clone script
2020-09-13 23:09:21 -04:00
Linux shared runners on GitLab.com provide a way to run commands in a CI
job before the runner attempts to run `git init` and `git fetch` to
2020-04-26 23:09:51 -04:00
download a GitLab repository. The
2020-06-11 23:08:22 -04:00
[`pre_clone_script` ](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section )
2020-04-26 23:09:51 -04:00
can be used for:
- Seeding the build directory with repository data
- Sending a request to a server
- Downloading assets from a CDN
- Any other commands that must run before the `git init`
2020-05-05 14:09:43 -04:00
To use this feature, define a [CI/CD variable ](../../ci/variables/README.md#create-a-custom-variable-in-the-ui ) called
2020-04-26 23:09:51 -04:00
`CI_PRE_CLONE_SCRIPT` that contains a bash script.
[This example ](../../development/pipelines.md#pre-clone-step )
demonstrates how you might use a pre-clone step to seed the build
directory.
2020-01-20 22:08:37 -05:00
#### `config.toml`
2018-03-23 12:29:55 -04:00
The full contents of our `config.toml` are:
2020-12-04 16:09:29 -05:00
NOTE:
2020-02-12 22:09:05 -05:00
Settings that are not public are shown as `X` .
2018-04-05 14:20:39 -04:00
**Google Cloud Platform**
```toml
concurrent = X
check_interval = 1
metrics_server = "X"
sentry_dsn = "X"
[[runners]]
name = "docker-auto-scale"
request_concurrency = X
url = "https://gitlab.com/"
token = "SHARED_RUNNER_TOKEN"
2020-04-26 23:09:51 -04:00
pre_clone_script = "eval \"$CI_PRE_CLONE_SCRIPT\""
2018-04-05 14:20:39 -04:00
executor = "docker+machine"
environment = [
2019-07-25 08:14:31 -04:00
"DOCKER_DRIVER=overlay2",
"DOCKER_TLS_CERTDIR="
2018-04-05 14:20:39 -04:00
]
limit = X
[runners.docker]
image = "ruby:2.5"
privileged = true
2019-07-25 08:14:31 -04:00
volumes = [
"/certs/client",
"/dummy-sys-class-dmi-id:/sys/class/dmi/id:ro" # Make kaniko builds work on GCP.
]
2018-04-05 14:20:39 -04:00
[runners.machine]
2019-07-25 08:14:31 -04:00
IdleCount = 50
IdleTime = 3600
MaxBuilds = 1 # For security reasons we delete the VM after job has finished so it's not reused.
2018-04-05 14:20:39 -04:00
MachineName = "srm-%s"
MachineDriver = "google"
MachineOptions = [
"google-project=PROJECT",
"google-disk-size=25",
"google-machine-type=n1-standard-1",
"google-username=core",
"google-tags=gitlab-com,srm",
"google-use-internal-ip",
"google-zone=us-east1-d",
2020-05-21 23:08:28 -04:00
"engine-opt=mtu=1460", # Set MTU for container interface, for more information check https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3214#note_82892928
2018-04-05 14:20:39 -04:00
"google-machine-image=PROJECT/global/images/IMAGE",
2019-07-25 08:14:31 -04:00
"engine-opt=ipv6", # This will create IPv6 interfaces in the containers.
"engine-opt=fixed-cidr-v6=fc00::/7",
"google-operation-backoff-initial-interval=2" # Custom flag from forked docker-machine, for more information check https://github.com/docker/machine/pull/4600
2018-04-05 14:20:39 -04:00
]
2020-08-10 14:09:54 -04:00
[[runners.machine.autoscaling]]
Periods = ["* * * * * sat,sun *"]
Timezone = "UTC"
IdleCount = 70
IdleTime = 3600
[[runners.machine.autoscaling]]
Periods = ["* 30-59 3 * * * * ", "* 0-30 4 * * * * "]
Timezone = "UTC"
IdleCount = 700
IdleTime = 3600
2018-04-05 14:20:39 -04:00
[runners.cache]
2019-07-25 08:14:31 -04:00
Type = "gcs"
2018-03-23 12:29:55 -04:00
Shared = true
2019-07-25 08:14:31 -04:00
[runners.cache.gcs]
CredentialsFile = "/path/to/file"
BucketName = "bucket-name"
2018-03-23 12:29:55 -04:00
```
2020-09-13 23:09:21 -04:00
### Windows shared runners (beta)
2020-01-20 22:08:37 -05:00
2020-10-20 20:08:57 -04:00
The Windows shared runners are in [beta ](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta )
and shouldn't be used for production workloads.
During this beta period, the [shared runner pipeline quota ](../admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota )
applies for groups and projects in the same manner as Linux runners. This may
change when the beta period ends, as discussed in this [related issue ](https://gitlab.com/gitlab-org/gitlab/-/issues/30834 ).
Windows shared runners on GitLab.com autoscale by launching virtual machines on
the Google Cloud Platform. This solution uses an
[autoscaling driver ](https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/autoscaler/tree/master/docs/readme.md )
2020-01-20 22:08:37 -05:00
developed by GitLab for the [custom executor ](https://docs.gitlab.com/runner/executors/custom.html ).
2020-10-20 20:08:57 -04:00
Windows shared runners execute your CI/CD jobs on `n1-standard-2` instances with
2 vCPUs and 7.5 GB RAM. You can find a full list of available Windows packages in
the [package documentation ](https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/gcp/windows-containers/blob/master/cookbooks/preinstalled-software/README.md ).
2020-01-20 22:08:37 -05:00
2020-09-13 23:09:21 -04:00
We want to keep iterating to get Windows shared runners in a stable state and
2020-10-20 20:08:57 -04:00
[generally available ](https://about.gitlab.com/handbook/product/gitlab-the-product/#generally-available-ga ).
2020-01-20 22:08:37 -05:00
You can follow our work towards this goal in the
[related epic ](https://gitlab.com/groups/gitlab-org/-/epics/2162 ).
#### Configuration
The full contents of our `config.toml` are:
2020-12-04 16:09:29 -05:00
NOTE:
2020-10-20 20:08:57 -04:00
Settings that aren't public are shown as `X` .
2020-02-11 22:08:55 -05:00
2020-01-20 22:08:37 -05:00
```toml
2020-02-11 22:08:55 -05:00
concurrent = X
2020-01-20 22:08:37 -05:00
check_interval = 3
[[runners]]
name = "windows-runner"
url = "https://gitlab.com/"
token = "TOKEN"
executor = "custom"
builds_dir = "C:\\GitLab-Runner\\builds"
cache_dir = "C:\\GitLab-Runner\\cache"
shell = "powershell"
[runners.custom]
config_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
config_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "config"]
prepare_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
prepare_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "prepare"]
run_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
run_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "run"]
cleanup_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
cleanup_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "cleanup"]
```
The full contents of our `autoscaler/config.toml` are:
```toml
Provider = "gcp"
Executor = "winrm"
OS = "windows"
LogLevel = "info"
LogFormat = "text"
LogFile = "C:\\GitLab-Runner\\autoscaler\\autoscaler.log"
VMTag = "windows"
[GCP]
ServiceAccountFile = "PATH"
Project = "some-project-df9323"
Zone = "us-east1-c"
MachineType = "n1-standard-2"
Image = "IMAGE"
DiskSize = 50
DiskType = "pd-standard"
Subnetwork = "default"
Network = "default"
Tags = ["TAGS"]
Username = "gitlab_runner"
[WinRM]
MaximumTimeout = 3600
ExecutionMaxRetries = 0
[ProviderCache]
Enabled = true
Directory = "C:\\GitLab-Runner\\autoscaler\\machines"
```
#### Example
Below is a simple `.gitlab-ci.yml` file to show how to start using the
2020-09-13 23:09:21 -04:00
Windows shared runners:
2020-01-20 22:08:37 -05:00
```yaml
.shared_windows_runners:
tags:
2020-07-03 05:08:53 -04:00
- shared-windows
- windows
- windows-1809
2020-01-20 22:08:37 -05:00
stages:
- build
- test
before_script:
2020-02-11 22:08:55 -05:00
- Set-Variable -Name "time" -Value (date -Format "%H:%m")
- echo ${time}
2020-01-20 22:08:37 -05:00
- echo "started by ${GITLAB_USER_NAME}"
build:
extends:
2020-07-03 05:08:53 -04:00
- .shared_windows_runners
2020-01-20 22:08:37 -05:00
stage: build
script:
2020-07-03 05:08:53 -04:00
- echo "running scripts in the build job"
2020-01-20 22:08:37 -05:00
test:
extends:
2020-07-03 05:08:53 -04:00
- .shared_windows_runners
2020-01-20 22:08:37 -05:00
stage: test
script:
2020-07-03 05:08:53 -04:00
- echo "running scripts in the test job"
2020-01-20 22:08:37 -05:00
```
#### Limitations and known issues
- All the limitations mentioned in our [beta
definition](https://about.gitlab.com/handbook/product/#beta).
- The average provisioning time for a new Windows VM is 5 minutes.
2020-02-14 04:08:43 -05:00
This means that you may notice slower build start times
2020-09-13 23:09:21 -04:00
on the Windows shared runner fleet during the beta. In a future
2020-11-19 22:09:15 -05:00
release we intend to update the autoscaler to enable
the pre-provisioning of virtual machines. This is intended to significantly reduce
2020-01-20 22:08:37 -05:00
the time it takes to provision a VM on the Windows fleet. You can
2020-05-29 11:08:14 -04:00
follow along in the [related issue ](https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/autoscaler/-/issues/32 ).
2020-09-13 23:09:21 -04:00
- The Windows shared runner fleet may be unavailable occasionally
2020-01-20 22:08:37 -05:00
for maintenance or updates.
2020-09-13 23:09:21 -04:00
- The Windows shared runner virtual machine instances do not use the
2020-11-19 22:09:15 -05:00
GitLab Docker executor. This means that you can't specify
2020-02-14 04:08:43 -05:00
[`image` ](../../ci/yaml/README.md#image ) or [`services` ](../../ci/yaml/README.md#services ) in
2020-01-20 22:08:37 -05:00
your pipeline configuration.
- For the beta release, we have included a set of software packages in
the base VM image. If your CI job requires additional software that's
2020-11-19 22:09:15 -05:00
not included in this list, then you must add installation
2020-11-11 13:09:10 -05:00
commands to [`before_script` ](../../ci/yaml/README.md#before_script ) or [`script` ](../../ci/yaml/README.md#script ) to install the required
2020-01-20 22:08:37 -05:00
software. Note that each job runs on a new VM instance, so the
installation of additional software packages needs to be repeated for
each job in your pipeline.
- The job may stay in a pending state for longer than the
2020-09-13 23:09:21 -04:00
Linux shared runners.
2020-01-20 22:08:37 -05:00
- There is the possibility that we introduce breaking changes which will
2020-09-13 23:09:21 -04:00
require updates to pipelines that are using the Windows shared runner
2020-01-20 22:08:37 -05:00
fleet.
2018-03-23 12:29:55 -04:00
## Sidekiq
2019-10-09 20:06:44 -04:00
GitLab.com runs [Sidekiq ](https://sidekiq.org ) with arguments `--timeout=4 --concurrency=4`
2018-03-23 12:29:55 -04:00
and the following environment variables:
2019-09-18 14:06:14 -04:00
| Setting | GitLab.com | Default |
|-------- |----------- |-------- |
2020-09-14 17:09:27 -04:00
| `SIDEKIQ_DAEMON_MEMORY_KILLER` | - | `1` |
2019-09-23 02:06:19 -04:00
| `SIDEKIQ_MEMORY_KILLER_MAX_RSS` | `2000000` | `2000000` |
2019-09-18 14:06:14 -04:00
| `SIDEKIQ_MEMORY_KILLER_HARD_LIMIT_RSS` | - | - |
| `SIDEKIQ_MEMORY_KILLER_CHECK_INTERVAL` | - | `3` |
| `SIDEKIQ_MEMORY_KILLER_GRACE_TIME` | - | `900` |
| `SIDEKIQ_MEMORY_KILLER_SHUTDOWN_WAIT` | - | `30` |
2020-11-13 13:09:11 -05:00
| `SIDEKIQ_LOG_ARGUMENTS` | `1` | `1` |
2018-03-23 12:29:55 -04:00
2020-12-04 16:09:29 -05:00
NOTE:
2019-09-23 02:06:19 -04:00
The `SIDEKIQ_MEMORY_KILLER_MAX_RSS` setting is `16000000` on Sidekiq import
nodes and Sidekiq export nodes.
2018-03-23 12:29:55 -04:00
## PostgreSQL
GitLab.com being a fairly large installation of GitLab means we have changed
various PostgreSQL settings to better suit our needs. For example, we use
streaming replication and servers in hot-standby mode to balance queries across
different database servers.
The list of GitLab.com specific settings (and their defaults) is as follows:
2020-06-11 23:08:22 -04:00
| Setting | GitLab.com | Default |
|:--------------------------------------|:--------------------------------------------------------------------|:--------------------------------------|
| `archive_command` | `/usr/bin/envdir /etc/wal-e.d/env /opt/wal-e/bin/wal-e wal-push %p` | empty |
| `archive_mode` | on | off |
| `autovacuum_analyze_scale_factor` | 0.01 | 0.01 |
| `autovacuum_max_workers` | 6 | 3 |
| `autovacuum_vacuum_cost_limit` | 1000 | -1 |
| `autovacuum_vacuum_scale_factor` | 0.01 | 0.02 |
| `checkpoint_completion_target` | 0.7 | 0.9 |
| `checkpoint_segments` | 32 | 10 |
| `effective_cache_size` | 338688MB | Based on how much memory is available |
| `hot_standby` | on | off |
| `hot_standby_feedback` | on | off |
| `log_autovacuum_min_duration` | 0 | -1 |
| `log_checkpoints` | on | off |
| `log_line_prefix` | `%t [%p]: [%l-1]` | empty |
| `log_min_duration_statement` | 1000 | -1 |
| `log_temp_files` | 0 | -1 |
| `maintenance_work_mem` | 2048MB | 16 MB |
| `max_replication_slots` | 5 | 0 |
| `max_wal_senders` | 32 | 0 |
| `max_wal_size` | 5GB | 1GB |
| `shared_buffers` | 112896MB | Based on how much memory is available |
| `shared_preload_libraries` | pg_stat_statements | empty |
| `shmall` | 30146560 | Based on the server's capabilities |
| `shmmax` | 123480309760 | Based on the server's capabilities |
| `wal_buffers` | 16MB | -1 |
| `wal_keep_segments` | 512 | 10 |
| `wal_level` | replica | minimal |
| `statement_timeout` | 15s | 60s |
| `idle_in_transaction_session_timeout` | 60s | 60s |
2018-03-23 12:29:55 -04:00
Some of these settings are in the process being adjusted. For example, the value
for `shared_buffers` is quite high and as such we are looking into adjusting it.
More information on this particular change can be found at
2020-05-21 23:08:28 -04:00
< https: / / gitlab . com / gitlab-com / infrastructure / - / issues / 1555 > . An up to date list
2018-03-23 12:29:55 -04:00
of proposed changes can be found at
2020-05-21 23:08:28 -04:00
< https: / / gitlab . com / gitlab-com / infrastructure / - / issues ? scope = all&utf8=%E2%9C%93&state=opened&label_name[]=database&label_name[]=change > .
2018-03-23 12:29:55 -04:00
2020-09-24 23:09:30 -04:00
## Puma
GitLab.com uses the default of 60 seconds for [Puma request timeouts ](https://docs.gitlab.com/omnibus/settings/puma.html#worker-timeout ).
2018-03-23 12:29:55 -04:00
## Unicorn
2020-04-21 11:21:10 -04:00
GitLab.com adjusts the memory limits for the [unicorn-worker-killer ](https://rubygems.org/gems/unicorn-worker-killer ) gem.
2018-03-23 12:29:55 -04:00
Base default:
2018-11-13 01:07:16 -05:00
- `memory_limit_min` = 750MiB
- `memory_limit_max` = 1024MiB
2018-03-23 12:29:55 -04:00
Web front-ends:
2018-11-13 01:07:16 -05:00
- `memory_limit_min` = 1024MiB
- `memory_limit_max` = 1280MiB
2018-03-23 12:29:55 -04:00
2019-08-01 22:41:52 -04:00
## GitLab.com-specific rate limits
2020-12-04 16:09:29 -05:00
NOTE:
2019-08-01 22:41:52 -04:00
See [Rate limits ](../../security/rate_limits.md ) for administrator
documentation.
IP blocks usually happen when GitLab.com receives unusual traffic from a single
IP address that the system views as potentially malicious based on rate limit
2020-11-19 22:09:15 -05:00
settings. After the unusual traffic ceases, the IP address is automatically
2019-08-01 22:41:52 -04:00
released depending on the type of block, as described below.
If you receive a `403 Forbidden` error for all requests to GitLab.com, please
check for any automated processes that may be triggering a block. For
2019-10-09 20:06:44 -04:00
assistance, contact [GitLab Support ](https://support.gitlab.com/hc/en-us )
2019-08-01 22:41:52 -04:00
with details, such as the affected IP address.
### HAProxy API throttle
2019-08-07 04:44:23 -04:00
GitLab.com responds with HTTP status code `429` to API requests that exceed 10
requests
2019-08-01 22:41:52 -04:00
per second per IP address.
The following example headers are included for all API requests:
2020-01-30 01:08:49 -05:00
```plaintext
2019-08-01 22:41:52 -04:00
RateLimit-Limit: 600
RateLimit-Observed: 6
RateLimit-Remaining: 594
RateLimit-Reset: 1563325137
RateLimit-ResetTime: Wed, 17 Jul 2019 00:58:57 GMT
```
Source:
- Search for `rate_limit_http_rate_per_minute` and `rate_limit_sessions_per_second` in [GitLab.com's current HAProxy settings ](https://gitlab.com/gitlab-cookbooks/gitlab-haproxy/blob/master/attributes/default.rb ).
2020-09-09 14:08:48 -04:00
### Pagination response headers
For performance reasons, if a query returns more than 10,000 records, GitLab
doesn't return the following headers:
2020-10-19 02:09:08 -04:00
- `x-total` .
- `x-total-pages` .
- `rel="last"` `link` .
2020-09-09 14:08:48 -04:00
2019-08-01 22:41:52 -04:00
### Rack Attack initializer
2019-08-07 04:44:23 -04:00
Details of rate limits enforced by [Rack Attack ](../../security/rack_attack.md ).
2019-08-01 22:41:52 -04:00
#### Protected paths throttle
2019-08-07 04:44:23 -04:00
GitLab.com responds with HTTP status code `429` to POST requests at protected
paths that exceed 10 requests per **minute** per IP address.
2019-08-01 22:41:52 -04:00
See the source below for which paths are protected. This includes user creation,
user confirmation, user sign in, and password reset.
This header is included in responses to blocked requests:
2020-01-30 01:08:49 -05:00
```plaintext
2019-08-01 22:41:52 -04:00
Retry-After: 60
```
2019-10-01 08:05:59 -04:00
See [Protected Paths ](../admin_area/settings/protected_paths.md ) for more details.
2019-08-01 22:41:52 -04:00
#### Git and container registry failed authentication ban
2019-08-23 15:52:53 -04:00
GitLab.com responds with HTTP status code `403` for 1 hour, if 30 failed
2019-08-01 22:41:52 -04:00
authentication requests were received in a 3-minute period from a single IP address.
This applies only to Git requests and container registry (`/jwt/auth`) requests
(combined).
2019-08-28 01:57:20 -04:00
This limit:
2019-08-01 22:41:52 -04:00
2019-08-28 01:57:20 -04:00
- Is reset by requests that authenticate successfully. For example, 29
failed authentication requests followed by 1 successful request, followed by 29
more failed authentication requests would not trigger a ban.
- Does not apply to JWT requests authenticated by `gitlab-ci-token` .
2019-08-23 15:52:53 -04:00
2019-08-01 22:41:52 -04:00
No response headers are provided.
### Admin Area settings
2019-08-29 23:42:44 -04:00
GitLab.com:
- Has [rate limits on raw endpoints ](../../user/admin_area/settings/rate_limits_on_raw_endpoints.md )
2019-09-01 20:19:30 -04:00
set to the default.
2019-08-29 23:42:44 -04:00
- Does not have the user and IP rate limits settings enabled.
2019-08-01 22:41:52 -04:00
2019-12-16 07:07:43 -05:00
### Visibility settings
On GitLab.com, projects, groups, and snippets created
As of GitLab 12.2 (July 2019), projects, groups, and snippets have the
2020-05-21 23:08:28 -04:00
[**Internal** visibility ](../../public_access/public_access.md#internal-projects ) setting [disabled on GitLab.com ](https://gitlab.com/gitlab-org/gitlab/-/issues/12388 ).
2019-12-16 07:07:43 -05:00
2020-03-06 01:08:30 -05:00
### SSH maximum number of connections
GitLab.com defines the maximum number of concurrent, unauthenticated SSH connections by
using the [MaxStartups setting ](http://man.openbsd.org/sshd_config.5#MaxStartups ).
If more than the maximum number of allowed connections occur concurrently, they are
dropped and users get
[an `ssh_exchange_identification` error ](../../topics/git/troubleshooting_git.md#ssh_exchange_identification-error ).
2020-05-27 11:08:11 -04:00
### Import/export
To help avoid abuse, project and group imports, exports, and export downloads are rate limited. See [Project import/export rate limits ](../../user/project/settings/import_export.md#rate-limits ) and [Group import/export rate limits ](../../user/group/settings/import_export.md#rate-limits ) for details.
2020-12-15 16:09:53 -05:00
GitLab.com Import/Export Rate Limits are set to the default except:
| Setting | GitLab.com | Default |
|:-------------------------------------------------|:-----------|:--------|
| Max Project Export requests per minute per user | 1 | 6 |
| Max Group Export requests per minute per user | 1 | 6 |
2020-10-08 08:08:31 -04:00
### Non-configurable limits
See [non-configurable limits ](../../security/rate_limits.md#non-configurable-limits ) for information on
rate limits that are not configurable, and therefore also used on GitLab.com.
2019-12-16 07:07:43 -05:00
## GitLab.com Logging
We use [Fluentd ](https://gitlab.com/gitlab-com/runbooks/tree/master/logging/doc#fluentd ) to parse our logs. Fluentd sends our logs to
[Stackdriver Logging ](https://gitlab.com/gitlab-com/runbooks/tree/master/logging/doc#stackdriver ) and [Cloud Pub/Sub ](https://gitlab.com/gitlab-com/runbooks/tree/master/logging/doc#cloud-pubsub ).
Stackdriver is used for storing logs long-term in Google Cold Storage (GCS). Cloud Pub/Sub
is used to forward logs to an [Elastic cluster ](https://gitlab.com/gitlab-com/runbooks/tree/master/logging/doc#elastic ) using [pubsubbeat ](https://gitlab.com/gitlab-com/runbooks/tree/master/logging/doc#pubsubbeat-vms ).
You can view more information in our runbooks such as:
2020-07-14 17:09:03 -04:00
- A [detailed list of what we're logging ](https://gitlab.com/gitlab-com/runbooks/-/tree/master/docs/logging#what-are-we-logging )
- Our [current log retention policies ](https://gitlab.com/gitlab-com/runbooks/-/tree/master/docs/logging#retention )
- A [diagram of our logging infrastructure ](https://gitlab.com/gitlab-com/runbooks/-/tree/master/docs/logging#logging-infrastructure-overview )
2019-12-16 07:07:43 -05:00
2020-10-22 14:09:01 -04:00
### Job Logs
By default, GitLab does not expire job logs. Job logs are retained indefinitely,
and can't be configured on GitLab.com to expire. You can erase job logs
[manually with the Jobs API ](../../api/jobs.md#erase-a-job ) or by
2020-11-16 16:09:02 -05:00
[deleting a pipeline ](../../ci/pipelines/index.md#delete-a-pipeline ).
2020-10-22 14:09:01 -04:00
2018-03-23 12:29:55 -04:00
## GitLab.com at scale
In addition to the GitLab Enterprise Edition Omnibus install, GitLab.com uses
the following applications and settings to achieve scale. All settings are
2019-08-29 10:52:08 -04:00
publicly available at [chef cookbooks ](https://gitlab.com/gitlab-cookbooks ).
2018-03-23 12:29:55 -04:00
2019-12-16 07:07:43 -05:00
### Elastic Cluster
2018-03-23 12:29:55 -04:00
2019-12-16 07:07:43 -05:00
We use Elasticsearch and Kibana for part of our monitoring solution:
2018-03-23 12:29:55 -04:00
2019-09-30 23:05:57 -04:00
- [`gitlab-cookbooks` / `gitlab-elk` · GitLab ](https://gitlab.com/gitlab-cookbooks/gitlab-elk )
- [`gitlab-cookbooks` / `gitlab_elasticsearch` · GitLab ](https://gitlab.com/gitlab-cookbooks/gitlab_elasticsearch )
2018-03-23 12:29:55 -04:00
2019-12-16 07:07:43 -05:00
### Fluentd
We use Fluentd to unify our GitLab logs:
- [`gitlab-cookbooks` / `gitlab_fluentd` · GitLab ](https://gitlab.com/gitlab-cookbooks/gitlab_fluentd )
2018-03-23 12:29:55 -04:00
### Prometheus
Prometheus complete our monitoring stack:
2019-09-30 23:05:57 -04:00
- [`gitlab-cookbooks` / `gitlab-prometheus` · GitLab ](https://gitlab.com/gitlab-cookbooks/gitlab-prometheus )
2018-03-23 12:29:55 -04:00
### Grafana
For the visualization of monitoring data:
2019-09-30 23:05:57 -04:00
- [`gitlab-cookbooks` / `gitlab-grafana` · GitLab ](https://gitlab.com/gitlab-cookbooks/gitlab-grafana )
2018-03-23 12:29:55 -04:00
### Sentry
Open source error tracking:
2019-09-30 23:05:57 -04:00
- [`gitlab-cookbooks` / `gitlab-sentry` · GitLab ](https://gitlab.com/gitlab-cookbooks/gitlab-sentry )
2018-03-23 12:29:55 -04:00
### Consul
Service discovery:
2019-09-30 23:05:57 -04:00
- [`gitlab-cookbooks` / `gitlab_consul` · GitLab ](https://gitlab.com/gitlab-cookbooks/gitlab_consul )
2018-03-23 12:29:55 -04:00
2020-03-13 14:09:39 -04:00
### HAProxy
2018-03-23 12:29:55 -04:00
High Performance TCP/HTTP Load Balancer:
2019-09-30 23:05:57 -04:00
- [`gitlab-cookbooks` / `gitlab-haproxy` · GitLab ](https://gitlab.com/gitlab-cookbooks/gitlab-haproxy )