Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
11ece334ec
commit
a2beea8ce7
|
|
@ -31,8 +31,6 @@ export default {
|
|||
RunnerProjects,
|
||||
RunnerUpgradeStatusBadge: () =>
|
||||
import('ee_component/ci/runner/components/runner_upgrade_status_badge.vue'),
|
||||
RunnerUpgradeStatusAlert: () =>
|
||||
import('ee_component/ci/runner/components/runner_upgrade_status_alert.vue'),
|
||||
RunnerTags,
|
||||
RunnerManagersDetail,
|
||||
TimeAgo,
|
||||
|
|
@ -92,7 +90,6 @@ export default {
|
|||
|
||||
<template>
|
||||
<div>
|
||||
<runner-upgrade-status-alert class="gl-my-4" :runner="runner" />
|
||||
<div class="gl-pt-4">
|
||||
<dl class="gl-mb-0 gl-display-grid runner-details-grid-template">
|
||||
<runner-detail :label="s__('Runners|Description')" :value="runner.description" />
|
||||
|
|
|
|||
|
|
@ -18,8 +18,7 @@ import {
|
|||
EXPANDED_LINE_TYPE,
|
||||
} from '../constants';
|
||||
import { prepareRawDiffFile } from '../utils/diff_file';
|
||||
|
||||
const SHA1 = /\b([a-f0-9]{40})\b/;
|
||||
import { extractFileHash } from '../utils/merge_request';
|
||||
|
||||
export const isAdded = (line) => ['new', 'new-nonewline'].includes(line.type);
|
||||
export const isRemoved = (line) => ['old', 'old-nonewline'].includes(line.type);
|
||||
|
|
@ -571,14 +570,16 @@ export function isUrlHashFileHeader(urlHash = '') {
|
|||
}
|
||||
|
||||
export function parseUrlHashAsFileHash(urlHash = '', currentDiffFileId = '') {
|
||||
const isNoteLink = isUrlHashNoteLink(urlHash);
|
||||
let id = urlHash.replace(/^#/, '');
|
||||
const hashless = urlHash.replace(/^#/, '');
|
||||
const isNoteLink = isUrlHashNoteLink(hashless);
|
||||
const extractedSha1 = extractFileHash({ input: hashless });
|
||||
let id = extractedSha1;
|
||||
|
||||
if (isNoteLink && currentDiffFileId) {
|
||||
id = currentDiffFileId;
|
||||
} else if (isUrlHashFileHeader(urlHash)) {
|
||||
id = id.replace('diff-content-', '');
|
||||
} else if (!SHA1.test(id) || isNoteLink) {
|
||||
} else if (isUrlHashFileHeader(hashless)) {
|
||||
id = hashless.replace('diff-content-', '');
|
||||
} else if (!extractedSha1 || isNoteLink) {
|
||||
id = null;
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -135,6 +135,7 @@ export default {
|
|||
:tracking="$options.tracking"
|
||||
:loading="isLoading"
|
||||
class="block confidentiality"
|
||||
data-testid="sidebar-confidentiality"
|
||||
>
|
||||
<template #collapsed>
|
||||
<div>
|
||||
|
|
|
|||
|
|
@ -144,9 +144,9 @@ class BulkImports::Entity < ApplicationRecord
|
|||
File.join(base_resource_path, 'export_relations')
|
||||
end
|
||||
|
||||
def export_relations_url_path(batched: false)
|
||||
if batched && bulk_import.supports_batched_export?
|
||||
Gitlab::Utils.add_url_parameters(export_relations_url_path_base, batched: batched)
|
||||
def export_relations_url_path
|
||||
if bulk_import.supports_batched_export?
|
||||
Gitlab::Utils.add_url_parameters(export_relations_url_path_base, batched: true)
|
||||
else
|
||||
export_relations_url_path_base
|
||||
end
|
||||
|
|
|
|||
|
|
@ -38,6 +38,7 @@ module Members
|
|||
|
||||
result
|
||||
rescue BlankInvitesError, TooManyInvitesError, MembershipLockedError => e
|
||||
Gitlab::ErrorTracking.log_exception(e, class: self.class.to_s, user_id: current_user.id)
|
||||
error(e.message)
|
||||
end
|
||||
|
||||
|
|
|
|||
|
|
@ -125,7 +125,7 @@ module BulkImports
|
|||
end
|
||||
|
||||
def export_url
|
||||
entity.export_relations_url_path(batched: Feature.enabled?(:bulk_imports_batched_import_export))
|
||||
entity.export_relations_url_path
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -1,8 +0,0 @@
|
|||
---
|
||||
name: bulk_imports_batched_import_export
|
||||
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/124434
|
||||
rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/406559
|
||||
milestone: '16.2'
|
||||
type: development
|
||||
group: group::import and integrate
|
||||
default_enabled: false
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class DropIndexNamespacesOnRunnersToken < Gitlab::Database::Migration[2.1]
|
||||
disable_ddl_transaction!
|
||||
|
||||
TABLE_NAME = :namespaces
|
||||
INDEX_NAME = :index_namespaces_on_runners_token
|
||||
|
||||
def up
|
||||
remove_concurrent_index_by_name TABLE_NAME, INDEX_NAME
|
||||
end
|
||||
|
||||
def down
|
||||
add_concurrent_index TABLE_NAME, :runners_token, unique: true, name: INDEX_NAME
|
||||
end
|
||||
end
|
||||
|
|
@ -0,0 +1 @@
|
|||
230cf1f339827016f9382c97983e78646d01f53f1023cf0030fac35e5a94666f
|
||||
|
|
@ -33121,8 +33121,6 @@ CREATE UNIQUE INDEX index_namespaces_on_push_rule_id ON namespaces USING btree (
|
|||
|
||||
CREATE INDEX index_namespaces_on_require_two_factor_authentication ON namespaces USING btree (require_two_factor_authentication);
|
||||
|
||||
CREATE UNIQUE INDEX index_namespaces_on_runners_token ON namespaces USING btree (runners_token);
|
||||
|
||||
CREATE UNIQUE INDEX index_namespaces_on_runners_token_encrypted ON namespaces USING btree (runners_token_encrypted);
|
||||
|
||||
CREATE INDEX index_namespaces_on_shared_and_extra_runners_minutes_limit ON namespaces USING btree (shared_runners_minutes_limit, extra_shared_runners_minutes_limit);
|
||||
|
|
|
|||
|
|
@ -0,0 +1,493 @@
|
|||
---
|
||||
stage: Systems
|
||||
group: Geo
|
||||
info: 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
|
||||
---
|
||||
|
||||
# Set up Geo for two single-node sites (with external PostgreSQL services) **(PREMIUM SELF)**
|
||||
|
||||
The following guide provides concise instructions on how to deploy GitLab Geo for a two single-node site installation using two Linux package instances and external PostgreSQL databases like RDS, Azure Database, or Google Cloud SQL.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- You have at least two independently working GitLab sites.
|
||||
To create the sites, see the [GitLab reference architectures documentation](../../reference_architectures/index.md).
|
||||
- One GitLab site serves as the **Geo primary site**. You can use different reference architecture sizes for each Geo site. If you already have a working GitLab instance, you can use it as the primary site.
|
||||
- The second GitLab site serves as the **Geo secondary site**. Geo supports multiple secondary sites.
|
||||
- The Geo primary site has at least a [GitLab Premium](https://about.gitlab.com/pricing/) license.
|
||||
You need only one license for all sites.
|
||||
- Confirm all sites meet the [requirements for running Geo](../index.md#requirements-for-running-geo).
|
||||
|
||||
## Set up Geo for Linux package (Omnibus)
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- You use PostgreSQL 12 or later,
|
||||
which includes the [`pg_basebackup` tool](https://www.postgresql.org/docs/12/app-pgbasebackup.html).
|
||||
|
||||
### Configure the primary site
|
||||
|
||||
1. SSH into your GitLab primary site and sign in as root:
|
||||
|
||||
```shell
|
||||
sudo -i
|
||||
```
|
||||
|
||||
1. Add a unique Geo site name to `/etc/gitlab/gitlab.rb`:
|
||||
|
||||
```ruby
|
||||
##
|
||||
## The unique identifier for the Geo site. See
|
||||
## https://docs.gitlab.com/ee/user/admin_area/geo_nodes.html#common-settings
|
||||
##
|
||||
gitlab_rails['geo_node_name'] = '<site_name_here>'
|
||||
```
|
||||
|
||||
1. To apply the change, reconfigure the primary site:
|
||||
|
||||
```shell
|
||||
gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
1. Define the site as your primary Geo site:
|
||||
|
||||
```shell
|
||||
gitlab-ctl set-geo-primary-node
|
||||
```
|
||||
|
||||
This command uses the `external_url` defined in `/etc/gitlab/gitlab.rb`.
|
||||
|
||||
### Configure the external database to be replicated
|
||||
|
||||
To set up an external database, you can either:
|
||||
|
||||
- Set up [streaming replication](https://www.postgresql.org/docs/12/warm-standby.html#STREAMING-REPLICATION-SLOTS) yourself (for example Amazon RDS, or bare metal not managed by the Linux package).
|
||||
- Manually perform the configuration of your Linux package installations as follows.
|
||||
|
||||
#### Leverage your cloud provider's tools to replicate the primary database
|
||||
|
||||
Given you have a primary site set up on AWS EC2 that uses RDS.
|
||||
You can now just create a read-only replica in a different region and the
|
||||
replication process is managed by AWS. Make sure you've set Network ACL (Access Control List), Subnet, and Security Group according to your needs, so the secondary Rails nodes can access the database.
|
||||
|
||||
The following instructions detail how to create a read-only replica for common
|
||||
cloud providers:
|
||||
|
||||
- Amazon RDS - [Creating a Read Replica](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Create)
|
||||
- Azure Database for PostgreSQL - [Create and manage read replicas in Azure Database for PostgreSQL](https://learn.microsoft.com/en-us/azure/postgresql/single-server/how-to-read-replicas-portal)
|
||||
- Google Cloud SQL - [Creating read replicas](https://cloud.google.com/sql/docs/postgres/replication/create-replica)
|
||||
|
||||
When your read-only replica is set up, you can skip to [configure your secondary site](#configure-the-secondary-site-to-use-the-external-read-replica).
|
||||
|
||||
### Configure the secondary site to use the external read-replica
|
||||
|
||||
With Linux package installations, the
|
||||
[`geo_secondary_role`](https://docs.gitlab.com/omnibus/roles/#gitlab-geo-roles)
|
||||
has three main functions:
|
||||
|
||||
1. Configure the replica database.
|
||||
1. Configure the tracking database.
|
||||
1. Enable the [Geo Log Cursor](../index.md#geo-log-cursor).
|
||||
|
||||
To configure the connection to the external read-replica database:
|
||||
|
||||
1. SSH into each **Rails, Sidekiq and Geo Log Cursor** node on your **secondary** site and login as root:
|
||||
|
||||
```shell
|
||||
sudo -i
|
||||
```
|
||||
|
||||
1. Edit `/etc/gitlab/gitlab.rb` and add the following
|
||||
|
||||
```ruby
|
||||
##
|
||||
## Geo Secondary role
|
||||
## - configure dependent flags automatically to enable Geo
|
||||
##
|
||||
roles ['geo_secondary_role']
|
||||
|
||||
# note this is shared between both databases,
|
||||
# make sure you define the same password in both
|
||||
gitlab_rails['db_password'] = '<your_password_here>'
|
||||
|
||||
gitlab_rails['db_username'] = 'gitlab'
|
||||
gitlab_rails['db_host'] = '<database_read_replica_host>'
|
||||
|
||||
# Disable the bundled Omnibus PostgreSQL, since we are
|
||||
# using an external PostgreSQL
|
||||
postgresql['enable'] = false
|
||||
```
|
||||
|
||||
1. Save the file and reconfigure GitLab:
|
||||
|
||||
```shell
|
||||
gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
In case you have connectivity issues to your replica database you can [check TCP connectivity](../../raketasks/maintenance.md) from your server with the following command:
|
||||
|
||||
```shell
|
||||
gitlab-rake gitlab:tcp_check[<replica FQDN>,5432]
|
||||
```
|
||||
|
||||
If this step fails, you might be using the wrong IP address, or a firewall might
|
||||
be preventing access to the site. Check the IP address, paying close
|
||||
attention to the difference between public and private addresses.
|
||||
If a firewall is present, ensure the secondary site is allowed to connect to the
|
||||
primary site on port 5432.
|
||||
|
||||
#### Manually replicate secret GitLab values
|
||||
|
||||
GitLab stores a number of secret values in `/etc/gitlab/gitlab-secrets.json`.
|
||||
This JSON file must be the same across each of the site nodes.
|
||||
You must manually replicate the secret file across all of your secondary sites, although
|
||||
[issue 3789](https://gitlab.com/gitlab-org/gitlab/-/issues/3789) proposes to change this behavior.
|
||||
|
||||
1. SSH into a Rails node on your primary site, and execute the command below:
|
||||
|
||||
```shell
|
||||
sudo cat /etc/gitlab/gitlab-secrets.json
|
||||
```
|
||||
|
||||
This displays the secrets you must replicate, in JSON format.
|
||||
|
||||
1. SSH into each node on your secondary Geo site and sign in as root:
|
||||
|
||||
```shell
|
||||
sudo -i
|
||||
```
|
||||
|
||||
1. Make a backup of any existing secrets:
|
||||
|
||||
```shell
|
||||
mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.`date +%F`
|
||||
```
|
||||
|
||||
1. Copy `/etc/gitlab/gitlab-secrets.json` from the primary site Rails node to each secondary site node.
|
||||
You can also copy-and-paste the file contents between nodes:
|
||||
|
||||
```shell
|
||||
sudo editor /etc/gitlab/gitlab-secrets.json
|
||||
|
||||
# paste the output of the `cat` command you ran on the primary
|
||||
# save and exit
|
||||
```
|
||||
|
||||
1. Ensure the file permissions are correct:
|
||||
|
||||
```shell
|
||||
chown root:root /etc/gitlab/gitlab-secrets.json
|
||||
chmod 0600 /etc/gitlab/gitlab-secrets.json
|
||||
```
|
||||
|
||||
1. To apply the changes, reconfigure every Rails, Sidekiq, and Gitaly secondary site node:
|
||||
|
||||
```shell
|
||||
gitlab-ctl reconfigure
|
||||
gitlab-ctl restart
|
||||
```
|
||||
|
||||
#### Manually replicate the primary site SSH host keys
|
||||
|
||||
1. SSH into each node on your secondary site and sign in as root:
|
||||
|
||||
```shell
|
||||
sudo -i
|
||||
```
|
||||
|
||||
1. Back up any existing SSH host keys:
|
||||
|
||||
```shell
|
||||
find /etc/ssh -iname 'ssh_host_*' -exec cp {} {}.backup.`date +%F` \;
|
||||
```
|
||||
|
||||
1. Copy OpenSSH host keys from the primary site.
|
||||
|
||||
- If you can access as root one of the primary site nodes serving SSH traffic (usually, the main GitLab Rails application nodes):
|
||||
|
||||
```shell
|
||||
# Run this from the secondary site, change `<primary_site_fqdn>` for the IP or FQDN of the server
|
||||
scp root@<primary_node_fqdn>:/etc/ssh/ssh_host_*_key* /etc/ssh
|
||||
```
|
||||
|
||||
- If you only have access through a user with `sudo` privileges:
|
||||
|
||||
```shell
|
||||
# Run this from the node on your primary site:
|
||||
sudo tar --transform 's/.*\///g' -zcvf ~/geo-host-key.tar.gz /etc/ssh/ssh_host_*_key*
|
||||
|
||||
# Run this on each node on your secondary site:
|
||||
scp <user_with_sudo>@<primary_site_fqdn>:geo-host-key.tar.gz .
|
||||
tar zxvf ~/geo-host-key.tar.gz -C /etc/ssh
|
||||
```
|
||||
|
||||
1. For each secondary site node, ensure the file permissions are correct:
|
||||
|
||||
```shell
|
||||
chown root:root /etc/ssh/ssh_host_*_key*
|
||||
chmod 0600 /etc/ssh/ssh_host_*_key
|
||||
```
|
||||
|
||||
1. To verify key fingerprint matches, execute the following command on both the primary and secondary nodes on each site:
|
||||
|
||||
```shell
|
||||
for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done
|
||||
```
|
||||
|
||||
You should get an output similar to the following:
|
||||
|
||||
```shell
|
||||
1024 SHA256:FEZX2jQa2bcsd/fn/uxBzxhKdx4Imc4raXrHwsbtP0M root@serverhostname (DSA)
|
||||
256 SHA256:uw98R35Uf+fYEQ/UnJD9Br4NXUFPv7JAUln5uHlgSeY root@serverhostname (ECDSA)
|
||||
256 SHA256:sqOUWcraZQKd89y/QQv/iynPTOGQxcOTIXU/LsoPmnM root@serverhostname (ED25519)
|
||||
2048 SHA256:qwa+rgir2Oy86QI+PZi/QVR+MSmrdrpsuH7YyKknC+s root@serverhostname (RSA)
|
||||
```
|
||||
|
||||
The output should be identical on both nodes.
|
||||
|
||||
1. Verify you have the correct public keys for the existing private keys:
|
||||
|
||||
```shell
|
||||
# This will print the fingerprint for private keys:
|
||||
for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done
|
||||
|
||||
# This will print the fingerprint for public keys:
|
||||
for file in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -lf $file; done
|
||||
```
|
||||
|
||||
The output for the public and private key commands should generate the same fingerprint.
|
||||
|
||||
1. For each secondary site node, restart `sshd`:
|
||||
|
||||
```shell
|
||||
# Debian or Ubuntu installations
|
||||
sudo service ssh reload
|
||||
|
||||
# CentOS installations
|
||||
sudo service sshd reload
|
||||
```
|
||||
|
||||
1. To verify SSH is still functional, from a new terminal, SSH into your GitLab secondary server.
|
||||
If you can't connect, make sure you have the correct permissions.
|
||||
|
||||
#### Set up fast lookup of authorized SSH keys
|
||||
|
||||
After the replication process is complete, you need to [configure fast lookup of authorized SSH keys](../../operations/fast_ssh_key_lookup.md).
|
||||
|
||||
NOTE:
|
||||
Authentication is handled by the primary site. Don't set up custom authentication for the secondary site.
|
||||
Any change that requires access to the Admin Area should be made in the primary site, because the
|
||||
secondary site is a read-only copy.
|
||||
|
||||
#### Add the secondary site
|
||||
|
||||
1. SSH into each Rails and Sidekiq node on your secondary site and sign in as root:
|
||||
|
||||
```shell
|
||||
sudo -i
|
||||
```
|
||||
|
||||
1. Edit `/etc/gitlab/gitlab.rb` and add a unique name for your site.
|
||||
|
||||
```ruby
|
||||
##
|
||||
## The unique identifier for the Geo site. See
|
||||
## https://docs.gitlab.com/ee/user/admin_area/geo_nodes.html#common-settings
|
||||
##
|
||||
gitlab_rails['geo_node_name'] = '<secondary_site_name_here>'
|
||||
```
|
||||
|
||||
Save the unique name for the next steps.
|
||||
|
||||
1. To apply the changes, reconfigure each Rails and Sidekiq node on your secondary site.
|
||||
|
||||
```shell
|
||||
gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
1. Go to the primary node GitLab instance:
|
||||
1. On the left sidebar, select **Search or go to**.
|
||||
1. Select **Admin Area**.
|
||||
1. Select **Geo > Sites**.
|
||||
1. Select **Add site**.
|
||||
|
||||
|
||||
|
||||
1. In **Name**, enter the value for `gitlab_rails['geo_node_name']` in
|
||||
`/etc/gitlab/gitlab.rb`. The values must match exactly.
|
||||
1. In **External URL**, enter the value for `external_url` in `/etc/gitlab/gitlab.rb`.
|
||||
It's okay if one values ends in `/` and the other doesn't. Otherwise, the values must
|
||||
match exactly.
|
||||
1. Optional. In **Internal URL (optional)**, enter an internal URL for the primary site.
|
||||
1. Optional. Select which groups or storage shards should be replicated by the
|
||||
secondary site. To replicate all, leave the field blank. See [selective synchronization](../replication/configuration.md#selective-synchronization).
|
||||
1. Select **Save changes**.
|
||||
1. SSH into each Rails and Sidekiq node on your secondary site and restart the services:
|
||||
|
||||
```shell
|
||||
sudo gitlab-ctl restart
|
||||
```
|
||||
|
||||
1. Check if there are any common issues with your Geo setup by running:
|
||||
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:geo:check
|
||||
```
|
||||
|
||||
If any of the checks fail, see the [troubleshooting documentation](../replication/troubleshooting.md).
|
||||
|
||||
1. To verify that the secondary site is reachable, SSH into a Rails or Sidekiq server on your primary site and run:
|
||||
|
||||
```shell
|
||||
sudo gitlab-rake gitlab:geo:check
|
||||
```
|
||||
|
||||
If any of the checks fail, check the [troubleshooting documentation](../replication/troubleshooting.md).
|
||||
|
||||
After the secondary site is added to the Geo administration page and restarted,
|
||||
the site automatically starts to replicate missing data from the primary site
|
||||
in a process known as backfill.
|
||||
|
||||
Meanwhile, the primary site starts to notify each secondary site of any changes, so
|
||||
that the secondary site can act on the notifications immediately.
|
||||
|
||||
Be sure the secondary site is running and accessible. You can sign in to the
|
||||
secondary site with the same credentials as were used with the primary site.
|
||||
|
||||
#### Enable Git access over HTTP/HTTPS and SSH
|
||||
|
||||
Geo synchronizes repositories over HTTP/HTTPS (enabled by default for new installations),
|
||||
and therefore requires this clone method to be enabled.
|
||||
If you convert an existing site to Geo, you should check that the clone method is enabled.
|
||||
|
||||
On the primary site:
|
||||
|
||||
1. On the left sidebar, select **Search or go to**.
|
||||
1. Select **Admin Area**.
|
||||
1. Select **Settings > General**.
|
||||
1. Expand **Visibility and access controls**.
|
||||
1. If you use Git over SSH:
|
||||
1. Ensure **Enabled Git access protocols** is set to **Both SSH and HTTP(S)**.
|
||||
1. Enable the [fast lookup of authorized SSH keys in the database](../../operations/fast_ssh_key_lookup.md) on both the primary and secondary sites.
|
||||
1. If you don't use Git over SSH, set **Enabled Git access protocols** to **Only HTTP(S)**.
|
||||
|
||||
#### Verify proper functioning of the secondary site
|
||||
|
||||
You can sign in to the secondary site with the same credentials you used with
|
||||
the primary site.
|
||||
|
||||
After you sign in:
|
||||
|
||||
1. On the left sidebar, select **Search or go to**.
|
||||
1. Select **Admin Area**.
|
||||
1. Select **Geo > Sites**.
|
||||
1. Verify that the site is correctly identified as a secondary Geo site, and that
|
||||
Geo is enabled.
|
||||
|
||||
The initial replication might take some time.
|
||||
You can monitor the synchronization process on each Geo site from the primary
|
||||
site **Geo Sites** dashboard in your browser.
|
||||
|
||||
|
||||
|
||||
## Configure the tracking database
|
||||
|
||||
NOTE:
|
||||
This step is optional in case you also want to have your tracking database set up externally on another server.
|
||||
|
||||
**Secondary** sites use a separate PostgreSQL installation as a tracking
|
||||
database to keep track of replication status and automatically recover from
|
||||
potential replication issues. The Linux package automatically configures a tracking database
|
||||
when `roles ['geo_secondary_role']` is set.
|
||||
If you want to run this database external to your Linux package installation, use the following instructions.
|
||||
|
||||
### Cloud-managed database services
|
||||
|
||||
If you are using a cloud-managed service for the tracking database, you may need
|
||||
to grant additional roles to your tracking database user (by default, this is
|
||||
`gitlab_geo`):
|
||||
|
||||
- Amazon RDS requires the [`rds_superuser`](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.html#Appendix.PostgreSQL.CommonDBATasks.Roles) role.
|
||||
- Azure Database for PostgreSQL requires the [`azure_pg_admin`](https://learn.microsoft.com/en-us/azure/postgresql/single-server/how-to-create-users#how-to-create-additional-admin-users-in-azure-database-for-postgresql) role.
|
||||
- Google Cloud SQL requires the [`cloudsqlsuperuser`](https://cloud.google.com/sql/docs/postgres/users#default-users) role.
|
||||
|
||||
Additional roles are needed for the installation of extensions during installation and upgrades. As an alternative,
|
||||
[ensure the extensions are installed manually, and read about the problems that may arise during future GitLab upgrades](../../../install/postgresql_extensions.md).
|
||||
|
||||
NOTE:
|
||||
If you want to use Amazon RDS as a tracking database, make sure it has access to
|
||||
the secondary database. Unfortunately, just assigning the same security group is not enough as
|
||||
outbound rules do not apply to RDS PostgreSQL databases. Therefore, you need to explicitly add an inbound
|
||||
rule to the read-replica's security group allowing any TCP traffic from
|
||||
the tracking database on port 5432.
|
||||
|
||||
### Create the tracking database
|
||||
|
||||
Create and configure the tracking database in your PostgreSQL instance:
|
||||
|
||||
1. Set up PostgreSQL according to the
|
||||
[database requirements document](../../../install/requirements.md#database).
|
||||
1. Set up a `gitlab_geo` user with a password of your choice, create the `gitlabhq_geo_production` database, and make the user an owner of the database.
|
||||
You can see an example of this setup in the [self-compiled installation documentation](../../../install/installation.md#7-database).
|
||||
1. If you are **not** using a cloud-managed PostgreSQL database, ensure that your secondary
|
||||
site can communicate with your tracking database by manually changing the
|
||||
`pg_hba.conf` that is associated with your tracking database.
|
||||
Remember to restart PostgreSQL afterwards for the changes to take effect:
|
||||
|
||||
```plaintext
|
||||
##
|
||||
## Geo Tracking Database Role
|
||||
## - pg_hba.conf
|
||||
##
|
||||
host all all <trusted tracking IP>/32 md5
|
||||
host all all <trusted secondary IP>/32 md5
|
||||
```
|
||||
|
||||
### Configure GitLab
|
||||
|
||||
Configure GitLab to use this database. These steps are for Linux package and Docker deployments.
|
||||
|
||||
1. SSH into a GitLab **secondary** server and login as root:
|
||||
|
||||
```shell
|
||||
sudo -i
|
||||
```
|
||||
|
||||
1. Edit `/etc/gitlab/gitlab.rb` with the connection parameters and credentials for
|
||||
the machine with the PostgreSQL instance:
|
||||
|
||||
```ruby
|
||||
geo_secondary['db_username'] = 'gitlab_geo'
|
||||
geo_secondary['db_password'] = '<your_password_here>'
|
||||
|
||||
geo_secondary['db_host'] = '<tracking_database_host>'
|
||||
geo_secondary['db_port'] = <tracking_database_port> # change to the correct port
|
||||
geo_postgresql['enable'] = false # don't use internal managed instance
|
||||
```
|
||||
|
||||
1. Save the file and reconfigure GitLab:
|
||||
|
||||
```shell
|
||||
gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
#### Manually set up the database schema (optional)
|
||||
|
||||
The reconfigure in the [steps above](#configure-gitlab) handles these steps automatically. These steps are provided in case something went wrong.
|
||||
|
||||
1. This task creates the database schema. It requires the database user to be a superuser.
|
||||
|
||||
```shell
|
||||
sudo gitlab-rake db:create:geo
|
||||
```
|
||||
|
||||
1. Applying Rails database migrations (schema and data updates) is also performed by reconfigure. If `geo_secondary['auto_migrate'] = false` is set, or
|
||||
the schema was created manually, this step is required:
|
||||
|
||||
```shell
|
||||
sudo gitlab-rake db:migrate:geo
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
See [troubleshooting Geo](../replication/troubleshooting.md).
|
||||
|
|
@ -32,14 +32,37 @@ Note the Redis node's IP address or hostname, port, and password (if required).
|
|||
1. Configure the GitLab application servers with the appropriate connection details
|
||||
for your external Redis service in your `/etc/gitlab/gitlab.rb` file:
|
||||
|
||||
When using a single Redis instance:
|
||||
|
||||
```ruby
|
||||
redis['enable'] = false
|
||||
|
||||
gitlab_rails['redis_host'] = 'redis.example.com'
|
||||
gitlab_rails['redis_port'] = 6379
|
||||
gitlab_rails['redis_host'] = '<redis_instance_url>'
|
||||
gitlab_rails['redis_port'] = '<redis_instance_port>'
|
||||
|
||||
# Required if Redis authentication is configured on the Redis node
|
||||
gitlab_rails['redis_password'] = 'Redis Password'
|
||||
gitlab_rails['redis_password'] = '<redis_password>'
|
||||
|
||||
# Set to true if instance is using Redis SSL
|
||||
gitlab_rails['redis_ssl'] = true
|
||||
```
|
||||
|
||||
When using separate Redis Cache and Persistent instances:
|
||||
|
||||
```ruby
|
||||
redis['enable'] = false
|
||||
|
||||
# Default Redis connection
|
||||
gitlab_rails['redis_host'] = '<redis_persistent_instance_url>'
|
||||
gitlab_rails['redis_port'] = '<redis_persistent_instance_port>'
|
||||
gitlab_rails['redis_password'] = '<redis_persistent_password>'
|
||||
|
||||
# Set to true if instance is using Redis SSL
|
||||
gitlab_rails['redis_ssl'] = true
|
||||
|
||||
# Redis Cache connection
|
||||
# Replace `redis://` with `rediss://` if using SSL
|
||||
gitlab_rails['redis_cache_instance'] = 'redis://:<redis_cache_password>@<redis_cache_instance_url>:<redis_cache_instance_port>'
|
||||
```
|
||||
|
||||
1. Reconfigure for the changes to take effect:
|
||||
|
|
@ -48,6 +71,15 @@ Note the Redis node's IP address or hostname, port, and password (if required).
|
|||
sudo gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
### Setting the Redis Cache instance as an LRU
|
||||
|
||||
When configuring a Redis Cache instance, it should be configured as a [Least Recently Used cache](https://redis.io/docs/manual/eviction/) (LRU) accordingly.
|
||||
|
||||
Configuring this depends on the cloud provider or service, but generally the following settings and values configure a cache:
|
||||
|
||||
- `maxmemory-policy` = `allkeys-lru`
|
||||
- `maxmemory-samples` = `5`
|
||||
|
||||
## Redis replication and failover with your own Redis servers
|
||||
|
||||
This is the documentation for configuring a scalable Redis setup when
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ full list of reference architectures, see
|
|||
<!-- Disable ordered list rule https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix -->
|
||||
<!-- markdownlint-disable MD029 -->
|
||||
1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) and [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
|
||||
2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) and [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
|
||||
2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instances](#provide-your-own-redis-instances) and [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
|
||||
- Redis is primarily single threaded. It's strongly recommended separating out the instances as specified into Cache and Persistent data to achieve optimum performance at this scale.
|
||||
3. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
|
||||
4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
|
||||
|
|
@ -829,11 +829,15 @@ to be used with GitLab. The following IPs will be used as an example:
|
|||
- `10.6.0.62`: Redis - Persistent Replica 1
|
||||
- `10.6.0.63`: Redis - Persistent Replica 2
|
||||
|
||||
### Provide your own Redis instance
|
||||
### Provide your own Redis instances
|
||||
|
||||
You can optionally use a third party external service for Redis as long as it meets the [requirements](../../install/requirements.md#redis).
|
||||
You can optionally use a [third party external service for the Redis Cache and Persistence instances](../redis/replication_and_failover_external.md#redis-as-a-managed-service-in-a-cloud-provider) with the following guidance:
|
||||
|
||||
A reputable provider or solution should be used for this. [Google Memorystore](https://cloud.google.com/memorystore/docs/redis/redis-overview) and [AWS ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html) are known to work. However, note that the Redis Cluster mode specifically isn't supported by GitLab. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
|
||||
- A reputable provider or solution should be used for this. [Google Memorystore](https://cloud.google.com/memorystore/docs/redis/redis-overview) and [AWS ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html) are known to work.
|
||||
- Redis Cluster mode is specifically not supported, but Redis Standalone with HA is.
|
||||
- The Redis Cache instance should be configured accordingly to be an [Least Recently Used cache](../redis/replication_and_failover_external.md#setting-the-redis-cache-instance-as-an-lru) (LRU).
|
||||
|
||||
For more information, see [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services).
|
||||
|
||||
### Configure the Redis Cache cluster
|
||||
|
||||
|
|
@ -2269,7 +2273,7 @@ services where applicable):
|
|||
<!-- Disable ordered list rule https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix -->
|
||||
<!-- markdownlint-disable MD029 -->
|
||||
1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) and [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
|
||||
2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) and [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
|
||||
2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instances](#provide-your-own-redis-instances) and [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
|
||||
- Redis is primarily single threaded. It's strongly recommended separating out the instances as specified into Cache and Persistent data to achieve optimum performance at this scale.
|
||||
3. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
|
||||
4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ full list of reference architectures, see
|
|||
<!-- Disable ordered list rule https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix -->
|
||||
<!-- markdownlint-disable MD029 -->
|
||||
1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) for more information.
|
||||
2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) for more information.
|
||||
2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instances](#provide-your-own-redis-instances) for more information.
|
||||
- Redis is primarily single threaded. It's strongly recommended separating out the instances as specified into Cache and Persistent data to achieve optimum performance at this scale.
|
||||
3. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
|
||||
4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
|
||||
|
|
@ -846,11 +846,15 @@ to be used with GitLab. The following IPs will be used as an example:
|
|||
- `10.6.0.62`: Redis - Persistent Replica 1
|
||||
- `10.6.0.63`: Redis - Persistent Replica 2
|
||||
|
||||
### Provide your own Redis instance
|
||||
### Provide your own Redis instances
|
||||
|
||||
You can optionally use a third party external service for Redis as long as it meets the [requirements](../../install/requirements.md#redis).
|
||||
You can optionally use a [third party external service for the Redis Cache and Persistence instances](../redis/replication_and_failover_external.md#redis-as-a-managed-service-in-a-cloud-provider) with the following guidance:
|
||||
|
||||
A reputable provider or solution should be used for this. [Google Memorystore](https://cloud.google.com/memorystore/docs/redis/redis-overview) and [AWS ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html) are known to work. However, note that the Redis Cluster mode specifically isn't supported by GitLab. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
|
||||
- A reputable provider or solution should be used for this. [Google Memorystore](https://cloud.google.com/memorystore/docs/redis/redis-overview) and [AWS ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html) are known to work.
|
||||
- Redis Cluster mode is specifically not supported, but Redis Standalone with HA is.
|
||||
- The Redis Cache instance should be configured accordingly to be an [Least Recently Used cache](../redis/replication_and_failover_external.md#setting-the-redis-cache-instance-as-an-lru) (LRU).
|
||||
|
||||
For more information, see [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services).
|
||||
|
||||
### Configure the Redis Cache cluster
|
||||
|
||||
|
|
@ -2288,7 +2292,7 @@ services where applicable):
|
|||
<!-- Disable ordered list rule https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix -->
|
||||
<!-- markdownlint-disable MD029 -->
|
||||
1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) for more information.
|
||||
2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) for more information.
|
||||
2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instances](#provide-your-own-redis-instances) for more information.
|
||||
- Redis is primarily single threaded. It's strongly recommended separating out the instances as specified into Cache and Persistent data to achieve optimum performance at this scale.
|
||||
3. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
|
||||
4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
|
||||
|
|
|
|||
|
|
@ -332,9 +332,12 @@ to be used with GitLab.
|
|||
|
||||
### Provide your own Redis instance
|
||||
|
||||
You can optionally use a third party external service for Redis as long as it meets the [requirements](../../install/requirements.md#redis).
|
||||
You can optionally use a [third party external service for the Redis instance](../redis/replication_and_failover_external.md#redis-as-a-managed-service-in-a-cloud-provider) with the following guidance:
|
||||
|
||||
A reputable provider or solution should be used for this. [Google Memorystore](https://cloud.google.com/memorystore/docs/redis/redis-overview) and [AWS ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html) are known to work. However, note that the Redis Cluster mode specifically isn't supported by GitLab. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
|
||||
- A reputable provider or solution should be used for this. [Google Memorystore](https://cloud.google.com/memorystore/docs/redis/redis-overview) and [AWS ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html) are known to work.
|
||||
- Redis Cluster mode is specifically not supported, but Redis Standalone with HA is.
|
||||
|
||||
For more information, see [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services).
|
||||
|
||||
### Standalone Redis using the Linux package
|
||||
|
||||
|
|
|
|||
|
|
@ -448,9 +448,12 @@ to be used with GitLab. The following IPs will be used as an example:
|
|||
|
||||
### Provide your own Redis instance
|
||||
|
||||
You can optionally use a third party external service for Redis as long as it meets the [requirements](../../install/requirements.md#redis).
|
||||
You can optionally use a [third party external service for the Redis instance](../redis/replication_and_failover_external.md#redis-as-a-managed-service-in-a-cloud-provider) with the following guidance:
|
||||
|
||||
A reputable provider or solution should be used for this. [Google Memorystore](https://cloud.google.com/memorystore/docs/redis/redis-overview) and [AWS ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html) are known to work. However, note that the Redis Cluster mode specifically isn't supported by GitLab. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
|
||||
- A reputable provider or solution should be used for this. [Google Memorystore](https://cloud.google.com/memorystore/docs/redis/redis-overview) and [AWS ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html) are known to work.
|
||||
- Redis Cluster mode is specifically not supported, but Redis Standalone with HA is.
|
||||
|
||||
For more information, see [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services).
|
||||
|
||||
### Standalone Redis using the Linux package
|
||||
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ full list of reference architectures, see
|
|||
<!-- Disable ordered list rule https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix -->
|
||||
<!-- markdownlint-disable MD029 -->
|
||||
1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) for more information.
|
||||
2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) for more information.
|
||||
2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instances](#provide-your-own-redis-instances) for more information.
|
||||
- Redis is primarily single threaded. It's strongly recommended separating out the instances as specified into Cache and Persistent data to achieve optimum performance at this scale.
|
||||
3. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
|
||||
4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
|
||||
|
|
@ -839,11 +839,15 @@ to be used with GitLab. The following IPs will be used as an example:
|
|||
- `10.6.0.62`: Redis - Persistent Replica 1
|
||||
- `10.6.0.63`: Redis - Persistent Replica 2
|
||||
|
||||
### Provide your own Redis instance
|
||||
### Provide your own Redis instances
|
||||
|
||||
You can optionally use a third party external service for Redis as long as it meets the [requirements](../../install/requirements.md#redis).
|
||||
You can optionally use a [third party external service for the Redis Cache and Persistence instances](../redis/replication_and_failover_external.md#redis-as-a-managed-service-in-a-cloud-provider) with the following guidance:
|
||||
|
||||
A reputable provider or solution should be used for this. [Google Memorystore](https://cloud.google.com/memorystore/docs/redis/redis-overview) and [AWS ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html) are known to work. However, note that the Redis Cluster mode specifically isn't supported by GitLab. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
|
||||
- A reputable provider or solution should be used for this. [Google Memorystore](https://cloud.google.com/memorystore/docs/redis/redis-overview) and [AWS ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html) are known to work.
|
||||
- Redis Cluster mode is specifically not supported, but Redis Standalone with HA is.
|
||||
- The Redis Cache instance should be configured accordingly to be an [Least Recently Used cache](../redis/replication_and_failover_external.md#setting-the-redis-cache-instance-as-an-lru) (LRU).
|
||||
|
||||
For more information, see [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services).
|
||||
|
||||
### Configure the Redis Cache cluster
|
||||
|
||||
|
|
@ -2287,7 +2291,7 @@ services where applicable):
|
|||
<!-- Disable ordered list rule https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix -->
|
||||
<!-- markdownlint-disable MD029 -->
|
||||
1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) for more information.
|
||||
2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) for more information.
|
||||
2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instances](#provide-your-own-redis-instances) for more information.
|
||||
- Redis is primarily single threaded. It's strongly recommended separating out the instances as specified into Cache and Persistent data to achieve optimum performance at this scale.
|
||||
3. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
|
||||
4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
|
||||
|
|
|
|||
|
|
@ -442,9 +442,12 @@ to be used with GitLab. The following IPs are used as an example:
|
|||
|
||||
### Provide your own Redis instance
|
||||
|
||||
You can optionally use a third party external service for Redis as long as it meets the [requirements](../../install/requirements.md#redis).
|
||||
You can optionally use a [third party external service for the Redis instance](../redis/replication_and_failover_external.md#redis-as-a-managed-service-in-a-cloud-provider) with the following guidance:
|
||||
|
||||
A reputable provider or solution should be used for this. [Google Memorystore](https://cloud.google.com/memorystore/docs/redis/redis-overview) and [AWS ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html) are known to work. However, note that the Redis Cluster mode specifically isn't supported by GitLab. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
|
||||
- A reputable provider or solution should be used for this. [Google Memorystore](https://cloud.google.com/memorystore/docs/redis/redis-overview) and [AWS ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html) are known to work.
|
||||
- Redis Cluster mode is specifically not supported, but Redis Standalone with HA is.
|
||||
|
||||
For more information, see [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services).
|
||||
|
||||
### Standalone Redis using the Linux package
|
||||
|
||||
|
|
|
|||
|
|
@ -341,6 +341,12 @@ If you choose to use a third party external service:
|
|||
1. However, if [Database Load Balancing](../postgresql/database_load_balancing.md) via Read Replicas is desired for further improved performance it's recommended to follow the node count for the Reference Architecture.
|
||||
1. If [GitLab Geo](../geo/index.md) is to be used the service will need to support Cross Region replication
|
||||
|
||||
### Recommendation notes for the Redis services
|
||||
|
||||
[When selecting to use an external Redis service](../redis/replication_and_failover_external.md#redis-as-a-managed-service-in-a-cloud-provider), it should run a standard, performant, and supported version.
|
||||
|
||||
Redis is primarily single threaded. For the 10,000 user and above Reference Architectures, separate out the instances as specified into Cache and Persistent data to achieve optimum performance at this scale.
|
||||
|
||||
#### Unsupported database services
|
||||
|
||||
Several database cloud provider services are known not to support the above or have been found to have other issues and aren't recommended:
|
||||
|
|
|
|||
|
|
@ -40,8 +40,9 @@ issue list with a search query, including labels or the test case's title.
|
|||
|
||||
Prerequisites:
|
||||
|
||||
- In a public project: You don't have to be a member of the project.
|
||||
- In a private project: You must have at least the Guest role for the project.
|
||||
- Non-confidential test case in a public project: You don't have to be a member of the project.
|
||||
- Non-confidential test case in a private project: You must have at least the Guest role for the project.
|
||||
- Confidential test case (regardless of project visibility): You must have at least the Reporter role for the project.
|
||||
|
||||
To view a test case:
|
||||
|
||||
|
|
@ -68,6 +69,21 @@ To edit a test case:
|
|||
1. Edit the test case's title or description.
|
||||
1. Select **Save changes**.
|
||||
|
||||
## Make a test case confidential
|
||||
|
||||
> Ability to make a test case confidential from the right sidebar [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/422120) in GitLab 16.5.
|
||||
|
||||
If you're working on a test case that contains private information, you can make it confidential.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- You must have at least the Reporter role.
|
||||
|
||||
To make a test case confidential: on the right sidebar, select **Edit** next to **Confidentiality**, and then select **Turn on**.
|
||||
|
||||
You can also use the `/confidential` [quick action](../../user/project/quick_actions.md) when both creating a new test case
|
||||
or editing an existing one.
|
||||
|
||||
## Archive a test case
|
||||
|
||||
When you want to stop using a test case, you can archive it. You can [reopen an archived test case](#reopen-an-archived-test-case) later.
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ GitLab is creating AI-assisted features across our DevSecOps platform. These fea
|
|||
| [Code review summary](project/merge_requests/ai_in_merge_requests.md#summarize-my-merge-request-review) | Helps ease merge request handoff between authors and reviewers and help reviewers efficiently understand suggestions. | [Google Vertex Codey APIs](https://cloud.google.com/vertex-ai/docs/generative-ai/code/code-models-overview) | SaaS only | [Experiment](../policy/experiment-beta-support.md#experiment) |
|
||||
| [Merge request template population](project/merge_requests/ai_in_merge_requests.md#fill-in-merge-request-templates) | Generate a description for the merge request based on the contents of the template. | [Google Vertex Codey APIs](https://cloud.google.com/vertex-ai/docs/generative-ai/code/code-models-overview) | SaaS only | [Experiment](../policy/experiment-beta-support.md#experiment) |
|
||||
| [Test generation](project/merge_requests/ai_in_merge_requests.md#generate-suggested-tests-in-merge-requests) | Automates repetitive tasks and helps catch bugs early. | [Google Vertex Codey APIs](https://cloud.google.com/vertex-ai/docs/generative-ai/code/code-models-overview) | SaaS only | [Experiment](../policy/experiment-beta-support.md#experiment) |
|
||||
| [Git suggestions](https://gitlab.com/gitlab-org/gitlab/-/issues/409636) | Helps you discover or recall Git commands when and where you need them. | OpenAI | SaaS only | [Experiment](../policy/experiment-beta-support.md#experiment) |
|
||||
| [Git suggestions](https://gitlab.com/gitlab-org/gitlab/-/issues/409636) | Helps you discover or recall Git commands when and where you need them. | [Google Vertex Codey APIs](https://cloud.google.com/vertex-ai/docs/generative-ai/code/code-models-overview) | SaaS only | [Experiment](../policy/experiment-beta-support.md#experiment) |
|
||||
| **Root cause analysis** | Assists you in determining the root cause for a pipeline failure and failed CI/CD build. | [Google Vertex Codey APIs](https://cloud.google.com/vertex-ai/docs/generative-ai/code/code-models-overview) | SaaS only | [Experiment](../policy/experiment-beta-support.md#experiment) |
|
||||
| [Issue description generation](#summarize-an-issue-with-issue-description-generation) | Generate issue descriptions. | [Google Vertex Codey APIs](https://cloud.google.com/vertex-ai/docs/generative-ai/code/code-models-overview) | SaaS only | [Experiment](../policy/experiment-beta-support.md#experiment) |
|
||||
|
||||
|
|
@ -36,8 +36,8 @@ In addition, all features built on large language models (LLM) from Google, Anth
|
|||
|
||||
Code Suggestions currently has its own settings:
|
||||
|
||||
- View [how to enable for self-managed](project/repository/code_suggestions/saas.md#enable-code-suggestions).
|
||||
- View [how to enable for SaaS](project/repository/code_suggestions/self_managed.md#enable-code-suggestions-on-self-managed-gitlab).
|
||||
- View [how to enable for self-managed](project/repository/code_suggestions/self_managed.md#enable-code-suggestions-on-self-managed-gitlab).
|
||||
- View [how to enable for SaaS](project/repository/code_suggestions/saas.md#enable-code-suggestions).
|
||||
|
||||
The use of Code Suggestions is also subject to the [Testing Terms of Use](https://about.gitlab.com/handbook/legal/testing-agreement/).
|
||||
|
||||
|
|
|
|||
|
|
@ -40667,9 +40667,6 @@ msgstr ""
|
|||
msgid "Runners|How do runners pick up jobs?"
|
||||
msgstr ""
|
||||
|
||||
msgid "Runners|How do we upgrade GitLab runner?"
|
||||
msgstr ""
|
||||
|
||||
msgid "Runners|IP Address"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -41179,9 +41176,6 @@ msgstr ""
|
|||
msgid "Runners|Up to date"
|
||||
msgstr ""
|
||||
|
||||
msgid "Runners|Upgrade GitLab Runner to match the version of GitLab you're running. Both %{linkStart}major and minor versions%{linkEnd} should match."
|
||||
msgstr ""
|
||||
|
||||
msgid "Runners|Upgrade Status"
|
||||
msgstr ""
|
||||
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@
|
|||
"@gitlab/cluster-client": "^1.3.0",
|
||||
"@gitlab/favicon-overlay": "2.0.0",
|
||||
"@gitlab/fonts": "^1.3.0",
|
||||
"@gitlab/svgs": "3.63.0",
|
||||
"@gitlab/svgs": "3.65.0",
|
||||
"@gitlab/ui": "66.7.0",
|
||||
"@gitlab/visual-review-tools": "1.7.3",
|
||||
"@gitlab/web-ide": "0.0.1-dev-20230921201626",
|
||||
|
|
|
|||
|
|
@ -6,14 +6,7 @@ module QA
|
|||
extend self
|
||||
|
||||
def onboard_user(wait: Capybara.default_max_wait_time)
|
||||
EE::Page::Registration::Welcome.perform do |welcome_page|
|
||||
if welcome_page.has_get_started_button?(wait: wait)
|
||||
welcome_page.select_role('Other')
|
||||
welcome_page.choose_setup_for_just_me_if_available
|
||||
welcome_page.choose_create_a_new_project_if_available
|
||||
welcome_page.click_get_started_button
|
||||
end
|
||||
end
|
||||
# Implemented in EE only
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -927,19 +927,21 @@ describe('DiffsStoreUtils', () => {
|
|||
|
||||
describe('parseUrlHashAsFileHash', () => {
|
||||
it.each`
|
||||
input | currentDiffId | resultId
|
||||
${'#note_12345'} | ${'1A2B3C'} | ${'1A2B3C'}
|
||||
${'note_12345'} | ${'1A2B3C'} | ${'1A2B3C'}
|
||||
${'#note_12345'} | ${undefined} | ${null}
|
||||
${'note_12345'} | ${undefined} | ${null}
|
||||
${'#diff-content-12345'} | ${undefined} | ${'12345'}
|
||||
${'diff-content-12345'} | ${undefined} | ${'12345'}
|
||||
${'#diff-content-12345'} | ${'98765'} | ${'12345'}
|
||||
${'diff-content-12345'} | ${'98765'} | ${'12345'}
|
||||
${'#e334a2a10f036c00151a04cea7938a5d4213a818'} | ${undefined} | ${'e334a2a10f036c00151a04cea7938a5d4213a818'}
|
||||
${'e334a2a10f036c00151a04cea7938a5d4213a818'} | ${undefined} | ${'e334a2a10f036c00151a04cea7938a5d4213a818'}
|
||||
${'#Z334a2a10f036c00151a04cea7938a5d4213a818'} | ${undefined} | ${null}
|
||||
${'Z334a2a10f036c00151a04cea7938a5d4213a818'} | ${undefined} | ${null}
|
||||
input | currentDiffId | resultId
|
||||
${'#note_12345'} | ${'1A2B3C'} | ${'1A2B3C'}
|
||||
${'note_12345'} | ${'1A2B3C'} | ${'1A2B3C'}
|
||||
${'#note_12345'} | ${undefined} | ${null}
|
||||
${'note_12345'} | ${undefined} | ${null}
|
||||
${'#diff-content-12345'} | ${undefined} | ${'12345'}
|
||||
${'diff-content-12345'} | ${undefined} | ${'12345'}
|
||||
${'#diff-content-12345'} | ${'98765'} | ${'12345'}
|
||||
${'diff-content-12345'} | ${'98765'} | ${'12345'}
|
||||
${'#e334a2a10f036c00151a04cea7938a5d4213a818'} | ${undefined} | ${'e334a2a10f036c00151a04cea7938a5d4213a818'}
|
||||
${'e334a2a10f036c00151a04cea7938a5d4213a818'} | ${undefined} | ${'e334a2a10f036c00151a04cea7938a5d4213a818'}
|
||||
${'#Z334a2a10f036c00151a04cea7938a5d4213a818'} | ${undefined} | ${null}
|
||||
${'Z334a2a10f036c00151a04cea7938a5d4213a818'} | ${undefined} | ${null}
|
||||
${'#e334a2a10f036c00151a04cea7938a5d4213a818_0_42'} | ${undefined} | ${'e334a2a10f036c00151a04cea7938a5d4213a818'}
|
||||
${'e334a2a10f036c00151a04cea7938a5d4213a818_0_42'} | ${undefined} | ${'e334a2a10f036c00151a04cea7938a5d4213a818'}
|
||||
`('returns $resultId for $input and $currentDiffId', ({ input, currentDiffId, resultId }) => {
|
||||
expect(utils.parseUrlHashAsFileHash(input, currentDiffId)).toBe(resultId);
|
||||
});
|
||||
|
|
|
|||
|
|
@ -271,7 +271,7 @@ RSpec.describe BulkImports::Entity, type: :model, feature_category: :importers d
|
|||
import = build(:bulk_import, source_version: '16.2.0')
|
||||
entity = build(:bulk_import_entity, :project_entity, bulk_import: import)
|
||||
|
||||
expect(entity.export_relations_url_path(batched: true))
|
||||
expect(entity.export_relations_url_path)
|
||||
.to eq("/projects/#{entity.source_xid}/export_relations?batched=true")
|
||||
end
|
||||
end
|
||||
|
|
@ -280,7 +280,7 @@ RSpec.describe BulkImports::Entity, type: :model, feature_category: :importers d
|
|||
it 'returns export relations url' do
|
||||
entity = build(:bulk_import_entity)
|
||||
|
||||
expect(entity.export_relations_url_path(batched: true))
|
||||
expect(entity.export_relations_url_path)
|
||||
.to eq("/groups/#{entity.source_xid}/export_relations")
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -167,12 +167,15 @@ RSpec.describe Members::CreateService, :aggregate_failures, :clean_gitlab_redis_
|
|||
let(:user_id) { '' }
|
||||
|
||||
it 'does not add a member' do
|
||||
expect(Gitlab::ErrorTracking)
|
||||
.to receive(:log_exception)
|
||||
.with(an_instance_of(described_class::BlankInvitesError), class: described_class.to_s, user_id: user.id)
|
||||
expect(Gitlab::EventStore)
|
||||
.not_to receive(:publish)
|
||||
.with(an_instance_of(Members::MembersAddedEvent))
|
||||
|
||||
expect(execute_service[:status]).to eq(:error)
|
||||
expect(execute_service[:message]).to be_present
|
||||
expect(execute_service[:message]).to eq(s_('AddMember|No users specified.'))
|
||||
expect(source.users).not_to include member
|
||||
expect(Onboarding::Progress.completed?(source.namespace, :user_added)).to be(false)
|
||||
end
|
||||
|
|
@ -182,6 +185,10 @@ RSpec.describe Members::CreateService, :aggregate_failures, :clean_gitlab_redis_
|
|||
let(:user_id) { 1.upto(101).to_a.join(',') }
|
||||
|
||||
it 'limits the number of users to 100' do
|
||||
expect(Gitlab::ErrorTracking)
|
||||
.to receive(:log_exception)
|
||||
.with(an_instance_of(described_class::TooManyInvitesError), class: described_class.to_s, user_id: user.id)
|
||||
|
||||
expect(execute_service[:status]).to eq(:error)
|
||||
expect(execute_service[:message]).to be_present
|
||||
expect(source.users).not_to include member
|
||||
|
|
|
|||
|
|
@ -51,15 +51,6 @@ Capybara.register_server :puma_via_workhorse do |app, port, host, **options|
|
|||
file.close! # We just want the filename
|
||||
|
||||
TestEnv.with_workhorse(host, port, socket_path) do
|
||||
# In cases of multiple installations of chromedriver, prioritize the version installed by SeleniumManager
|
||||
# selenium-manager doesn't work with Linux arm64 yet:
|
||||
# https://github.com/SeleniumHQ/selenium/issues/11357
|
||||
if RUBY_PLATFORM.include?('x86_64-linux') || RUBY_PLATFORM.include?('darwin')
|
||||
chrome_options = Selenium::WebDriver::Chrome::Options.chrome
|
||||
chromedriver_path = File.dirname(Selenium::WebDriver::SeleniumManager.driver_path(chrome_options))
|
||||
ENV['PATH'] = "#{chromedriver_path}:#{ENV['PATH']}" # rubocop:disable RSpec/EnvAssignment
|
||||
end
|
||||
|
||||
Capybara.servers[:puma].call(app, nil, socket_path, **options)
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -127,20 +127,6 @@ RSpec.describe BulkImports::ExportRequestWorker, feature_category: :importers do
|
|||
|
||||
described_class.new.perform(entity.id)
|
||||
end
|
||||
|
||||
context 'when bulk_imports_batched_import_export feature flag is disabled' do
|
||||
it 'requests relation export without batched param' do
|
||||
stub_feature_flags(bulk_imports_batched_import_export: false)
|
||||
|
||||
expected_url = "/projects/#{entity.source_xid}/export_relations"
|
||||
|
||||
expect_next_instance_of(BulkImports::Clients::HTTP) do |client|
|
||||
expect(client).to receive(:post).with(expected_url)
|
||||
end
|
||||
|
||||
described_class.new.perform(entity.id)
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
|
|
|
|||
|
|
@ -1269,10 +1269,10 @@
|
|||
stylelint-declaration-strict-value "1.9.2"
|
||||
stylelint-scss "5.1.0"
|
||||
|
||||
"@gitlab/svgs@3.63.0":
|
||||
version "3.63.0"
|
||||
resolved "https://registry.yarnpkg.com/@gitlab/svgs/-/svgs-3.63.0.tgz#48e41f50e6b03bcd065eafebf44b8c0f23de3df3"
|
||||
integrity sha512-rmEljjWhF7iieTjdx2edcsbSqgnW6AdD5Ou37p+cdlIll3lCcK85HpB5Kq474FNLCGoyTaVtnwpURBbWQMv/cg==
|
||||
"@gitlab/svgs@3.65.0":
|
||||
version "3.65.0"
|
||||
resolved "https://registry.yarnpkg.com/@gitlab/svgs/-/svgs-3.65.0.tgz#0dace141f1dcac339ae5fc145176ea36f7774c64"
|
||||
integrity sha512-hv7k48brF1xi2JaQ6WkQoSYZyuHx1h1YkX+AAzDRWyugDW0oePe0h9kpsBlggDo843Ae/Vm+4uC6oA9TPgh2dw==
|
||||
|
||||
"@gitlab/ui@66.7.0":
|
||||
version "66.7.0"
|
||||
|
|
|
|||
Loading…
Reference in New Issue