kotovalexarian-likes-gitlab
/
gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2022-09-09 12:12:03 +00:00
parent 6021fa2fc6
commit 704ed7ea39
33 changed files with 446 additions and 304 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

52
app/assets/javascripts/issuable/issuable_form.js
View File

@ -50,6 +50,15 @@ function getFallbackKey() {
}
export default class IssuableForm {
static addAutosave(map, id, $input, searchTerm, fallbackKey) {
if ($input.length) {
map.set(
id,
new Autosave($input, [document.location.pathname, searchTerm, id], `${fallbackKey}=${id}`),
);
}
}
constructor(form) {
if (form.length === 0) {
return;
@ -85,7 +94,7 @@ export default class IssuableForm {
return;
}
this.initAutosave();
this.autosaves = this.initAutosave();
this.form.on('submit', this.handleSubmit);
this.form.on('click', '.btn-cancel, .js-reset-autosave', this.resetAutosave);
this.form.find('.js-unwrap-on-load').unwrap();
@ -101,7 +110,10 @@ export default class IssuableForm {
container: $issuableDueDate.parent().get(0),
parse: (dateString) => parsePikadayDate(dateString),
toString: (date) => pikadayToString(date),
onSelect: (dateText) => $issuableDueDate.val(calendar.toString(dateText)),
onSelect: (dateText) => {
$issuableDueDate.val(calendar.toString(dateText));
if (this.autosaves.has('due_date')) this.autosaves.get('due_date').save();
},
firstDay: gon.first_day_of_week,
});
calendar.setDate(parsePikadayDate($issuableDueDate.val()));
@ -115,17 +127,30 @@ export default class IssuableForm {
}
initAutosave() {
this.autosaveTitle = new Autosave(
this.titleField,
[document.location.pathname, this.searchTerm, 'title'],
`${this.fallbackKey}=title`,
const autosaveMap = new Map();
IssuableForm.addAutosave(
autosaveMap,
'title',
this.form.find('input[name*="[title]"]'),
this.searchTerm,
this.fallbackKey,
);
IssuableForm.addAutosave(
autosaveMap,
'description',
this.form.find('textarea[name*="[description]"]'),
this.searchTerm,
this.fallbackKey,
);
IssuableForm.addAutosave(
autosaveMap,
'due_date',
this.form.find('input[name*="[due_date]"]'),
this.searchTerm,
this.fallbackKey,
);
this.autosaveDescription = new Autosave(
this.descriptionField,
[document.location.pathname, this.searchTerm, 'description'],
`${this.fallbackKey}=description`,
);
return autosaveMap;
}
handleSubmit() {
@ -133,8 +158,9 @@ export default class IssuableForm {
}
resetAutosave() {
this.autosaveTitle.reset();
this.autosaveDescription.reset();
this.autosaves.forEach((autosaveItem) => {
autosaveItem?.reset();
});
}
initWip() {

11
app/assets/javascripts/issues/list/constants.js
View File

@ -147,6 +147,7 @@ export const TOKEN_TYPE_EPIC = 'epic_id';
export const TOKEN_TYPE_WEIGHT = 'weight';
export const TOKEN_TYPE_CONTACT = 'crm_contact';
export const TOKEN_TYPE_ORGANIZATION = 'crm_organization';
export const TOKEN_TYPE_HEALTH = 'health_status';
export const TYPE_TOKEN_TASK_OPTION = { icon: 'task-done', title: 'task', value: 'task' };
@ -323,6 +324,16 @@ export const filters = {
},
},
},
[TOKEN_TYPE_HEALTH]: {
[API_PARAM]: {
[NORMAL_FILTER]: 'healthStatus',
},
[URL_PARAM]: {
[OPERATOR_IS]: {
[NORMAL_FILTER]: 'health_status',
},
},
},
[TOKEN_TYPE_CONTACT]: {
[API_PARAM]: {
[NORMAL_FILTER]: 'crmContactId',

16
app/assets/javascripts/pipeline_editor/pipeline_editor_app.vue
View File

@ -47,6 +47,7 @@ export default {
currentCiFileContent: '',
failureType: null,
failureReasons: [],
hasBranchLoaded: false,
initialCiFileContent: '',
isFetchingCommitSha: false,
isLintUnavailable: false,
@ -234,7 +235,7 @@ export default {
return this.lastCommittedContent !== this.currentCiFileContent;
},
isBlobContentLoading() {
return this.$apollo.queries.initialCiFileContent.loading;
return !this.hasBranchLoaded || this.$apollo.queries.initialCiFileContent.loading;
},
isCiConfigDataLoading() {
return this.$apollo.queries.ciConfigData.loading;
@ -243,7 +244,7 @@ export default {
return this.currentCiFileContent === '';
},
shouldSkipBlobContentQuery() {
return this.isNewCiConfigFile || this.lastCommittedContent || !this.currentBranch;
return this.isNewCiConfigFile || this.lastCommittedContent || !this.hasBranchLoaded;
},
shouldSkipCiConfigQuery() {
return !this.currentCiFileContent || !this.commitSha;
@ -264,6 +265,17 @@ export default {
},
},
watch: {
currentBranch: {
immediate: true,
handler(branch) {
// currentBranch is a client query so it starts off undefined. In the index.js,
// write to the apollo cache. Once that operation is done, we can safely do operations
// that require the branch to have loaded.
if (branch) {
this.hasBranchLoaded = true;
}
},
},
isEmpty(flag) {
if (flag) {
this.setAppStatus(EDITOR_APP_STATUS_EMPTY);

2
app/assets/javascripts/runner/components/cells/runner_stacked_summary_cell.vue
View File

@ -64,7 +64,7 @@ export default {
:title="$options.i18n.I18N_LOCKED_RUNNER_DESCRIPTION"
name="lock"
/>
<runner-type-badge :type="runner.runnerType" size="sm" />
<runner-type-badge :type="runner.runnerType" size="sm" class="gl-vertical-align-middle" />
</div>
<div class="gl-ml-auto gl-display-inline-flex gl-max-w-full gl-py-2">

2
app/assets/javascripts/vue_merge_request_widget/components/approvals/approvals_summary.vue
View File

@ -103,7 +103,7 @@ export default {
<span v-if="approvalLeftMessage">{{ message }}</span>
<span v-else class="gl-font-weight-bold">{{ message }}</span>
<user-avatar-list
class="gl-display-inline-block gl-vertical-align-middle"
class="gl-display-inline-block gl-vertical-align-middle gl-pt-1"
:img-size="24"
:items="approvers"
/>

8
app/assets/javascripts/vue_merge_request_widget/components/deployment/deployment_info.vue
View File

@ -74,16 +74,12 @@ export default {
<div class="js-deployment-info deployment-info">
<template v-if="hasDeploymentMeta">
<span>{{ deployedText }}</span>
<tooltip-on-truncate
:title="deployment.name"
truncate-target="child"
class="deploy-link label-truncate"
>
<tooltip-on-truncate :title="deployment.name" truncate-target="child" class="label-truncate">
<gl-link
:href="deployment.url"
target="_blank"
rel="noopener noreferrer nofollow"
class="js-deploy-meta gl-font-sm"
class="js-deploy-meta gl-font-sm gl-pb-1"
>
{{ deployment.name }}
</gl-link>

2
app/assets/javascripts/vue_merge_request_widget/components/extensions/base.vue
View File

@ -319,7 +319,7 @@ export default {
:status="statusIconName"
:is-loading="isLoadingSummary"
:class="{ 'gl-cursor-pointer': isCollapsible }"
class="gl-p-5"
class="gl-p-5 gl--flex-center"
@mousedown="onRowMouseDown"
@mouseup="onRowMouseUp"
>

2
app/assets/javascripts/vue_merge_request_widget/components/mr_widget_icon.vue
View File

@ -13,7 +13,7 @@ export default {
</script>
<template>
<div class="circle-icon-container gl-mr-3 align-self-start">
<div class="circle-icon-container gl-mr-3 align-self-start gl-mt-2">
<gl-icon :name="name" :size="24" />
</div>
</template>

2
app/assets/javascripts/work_items/components/work_item_labels.vue
View File

@ -219,7 +219,7 @@ export default {
class="add-labels gl-min-w-fit-content gl-display-flex gl-align-items-center gl-text-gray-400 gl-pr-4 gl-top-2"
data-testid="empty-state"
>
<span v-if="canUpdate" class="gl-ml-2">{{ __('Select labels') }}</span>
<span v-if="canUpdate" class="gl-ml-2">{{ __('Add labels') }}</span>
<span v-else class="gl-ml-2">{{ __('None') }}</span>
</div>
</template>

23
app/controllers/help_controller.rb
View File

@ -12,8 +12,7 @@ class HelpController < ApplicationController
YAML_FRONT_MATTER_REGEXP = /\A(---\s*\n.*?\n?)^((---|\.\.\.)\s*$\n?)/m.freeze
def index
# Remove YAML frontmatter so that it doesn't look weird
@help_index = File.read(path_to_doc('index.md')).sub(YAML_FRONT_MATTER_REGEXP, '')
@help_index = get_markdown_without_frontmatter(path_to_doc('index.md'))
# Prefix Markdown links with `help/` unless they are external links.
# '//' not necessarily part of URL, e.g., mailto:mail@example.com
@ -59,8 +58,25 @@ class HelpController < ApplicationController
@instance_configuration = InstanceConfiguration.new
end
def drawers
@clean_path = Rack::Utils.clean_path_info(params[:markdown_file])
@path = path_to_doc("#{@clean_path}.md")
if File.exist?(@path)
render :drawers, formats: :html, layout: false
else
head :not_found
end
end
private
# Remove YAML frontmatter so that it doesn't look weird
helper_method :get_markdown_without_frontmatter
def get_markdown_without_frontmatter(path)
File.read(path).gsub(YAML_FRONT_MATTER_REGEXP, '')
end
def redirect_to_documentation_website?
Gitlab::UrlSanitizer.valid_web?(documentation_url)
end
@ -100,8 +116,7 @@ class HelpController < ApplicationController
path = path_to_doc("#{@path}.md")
if File.exist?(path)
# Remove YAML frontmatter so that it doesn't look weird
@markdown = File.read(path).gsub(YAML_FRONT_MATTER_REGEXP, '')
@markdown = get_markdown_without_frontmatter(path)
render :show, formats: :html
else

14
app/helpers/jira_connect_helper.rb
View File

@ -1,7 +1,7 @@
# frozen_string_literal: true
module JiraConnectHelper
def jira_connect_app_data(subscriptions)
def jira_connect_app_data(subscriptions, installation)
skip_groups = subscriptions.map(&:namespace_id)
{
@ -11,14 +11,16 @@ module JiraConnectHelper
subscriptions_path: jira_connect_subscriptions_path(format: :json),
users_path: current_user ? nil : jira_connect_users_path, # users_path is used to determine if user is signed in
gitlab_user_path: current_user ? user_path(current_user) : nil,
oauth_metadata: Feature.enabled?(:jira_connect_oauth, current_user) ? jira_connect_oauth_data.to_json : nil
oauth_metadata: Feature.enabled?(:jira_connect_oauth, current_user) ? jira_connect_oauth_data(installation).to_json : nil
}
end
private
def jira_connect_oauth_data
oauth_authorize_url = oauth_authorization_url(
def jira_connect_oauth_data(installation)
oauth_instance_url = installation.oauth_authorization_url
oauth_authorize_path = oauth_authorization_path(
client_id: Gitlab::CurrentSettings.jira_connect_application_key,
response_type: 'code',
scope: 'api',
@ -27,8 +29,8 @@ module JiraConnectHelper
)
{
oauth_authorize_url: oauth_authorize_url,
oauth_token_url: oauth_token_url,
oauth_authorize_url: Gitlab::Utils.append_path(oauth_instance_url, oauth_authorize_path),
oauth_token_url: Gitlab::Utils.append_path(oauth_instance_url, oauth_token_path),
state: oauth_state,
oauth_token_payload: {
grant_type: :authorization_code,

6
app/models/jira_connect_installation.rb
View File

@ -24,4 +24,10 @@ class JiraConnectInstallation < ApplicationRecord
def client
Atlassian::JiraConnect::Client.new(base_url, shared_secret)
end
def oauth_authorization_url
return Gitlab.config.gitlab.host if instance_url.blank? || Feature.disabled?(:jira_connect_oauth_self_managed)
instance_url
end
end

2
app/views/help/drawers.html.haml Normal file
View File

@ -0,0 +1,2 @@
= cache(@clean_path, expires_in: 1.day) do
= markdown get_markdown_without_frontmatter(@path)

2
app/views/jira_connect/subscriptions/index.html.haml
View File

@ -1,4 +1,4 @@
.js-jira-connect-app{ data: jira_connect_app_data(@subscriptions) }
.js-jira-connect-app{ data: jira_connect_app_data(@subscriptions, @current_jira_installation) }
= webpack_bundle_tag 'performance_bar' if performance_bar_enabled?
= webpack_bundle_tag 'jira_connect_app'

2
config/feature_categories.yml
View File

@ -115,7 +115,7 @@
- secret_detection
- secrets_management
- security_benchmarking
- security_orchestration
- security_policy_management
- service_desk
- service_ping
- snippets

1
config/routes/help.rb
View File

@ -3,4 +3,5 @@
get 'help' => 'help#index'
get 'help/shortcuts' => 'help#shortcuts'
get 'help/instance_configuration' => 'help#instance_configuration'
get 'help/drawers/*markdown_file' => 'help#drawers'
get 'help/*path' => 'help#show', as: :help_page

2
config/sidekiq_queues.yml
View File

@ -199,6 +199,8 @@
- 2
- - gitlab_subscriptions_notify_seats_exceeded
- 1
- - gitlab_subscriptions_trials_apply_trial
- 1
- - google_cloud_create_cloudsql_instance
- 1
- - group_destroy

7
doc/administration/geo/replication/version_specific_upgrades.md
View File

@ -157,6 +157,13 @@ to perform the following additional steps for the zero-downtime upgrade:
sudo gitlab-rake db:migrate
```
1. Hot reload `puma` and `sidekiq` services:
```shell
sudo gitlab-ctl hup puma
sudo gitlab-ctl restart sidekiq
```
If you have already run the final `sudo gitlab-rake db:migrate` command on the deploy node and have
encountered the [column rename issue](https://gitlab.com/gitlab-org/gitlab/-/issues/324160), you might
see the following error:

18
doc/administration/raketasks/maintenance.md
View File

@ -326,14 +326,20 @@ database: gitlabhq_production
Database migrations can be stuck in an incomplete state, with a `down`
status in the output of the `sudo gitlab-rake db:migrate:status` command.
To complete these migrations, use the following Rake task:
1. To complete these migrations, use the following Rake task:
```shell
sudo gitlab-rake db:migrate
```
```shell
sudo gitlab-rake db:migrate
```
After the command completes, run `sudo gitlab-rake db:migrate:status` to check if all
migrations are completed (have an `up` status).
1. After the command completes, run `sudo gitlab-rake db:migrate:status` to check if all migrations are completed (have an `up` status).
1. Hot reload `puma` and `sidekiq` services:
```shell
sudo gitlab-ctl hup puma
sudo gitlab-ctl restart sidekiq
```
## Rebuild database indexes

74
doc/administration/reference_architectures/10k_users.md
View File

@ -188,10 +188,11 @@ To set up GitLab and its components to accommodate up to 10,000 users:
environment.
1. [Configure the object storage](#configure-the-object-storage)
used for shared data objects.
1. [Configure NFS](#configure-nfs-optional) (optional, and not recommended)
to have shared disk storage service as an alternative to Gitaly or object
storage.
1. [Configure Advanced Search](#configure-advanced-search) (optional) for faster,
more advanced code search across your entire GitLab instance.
1. [Configure NFS](#configure-nfs)
to have shared disk storage service for certain GitLab operations (non Gitaly or Object Storage).
The servers start on the same 10.6.0.0/24 private network range, and can
connect to each other freely on these addresses.
@ -2011,7 +2012,7 @@ On each node perform the following:
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. If you're [using NFS](#configure-nfs):
1. If you're [using NFS](#configure-nfs-optional):
1. If necessary, install the NFS client utility packages using the following
commands:
@ -2177,7 +2178,7 @@ To configure the Monitoring node:
## Configure the object storage
GitLab supports using an object storage service for holding numerous types of data.
It's recommended over [NFS](#configure-nfs) and in general it's better
It's recommended over [NFS](#configure-nfs-optional) and in general it's better
in larger setups as object storage is typically much more performant, reliable,
and scalable.
@ -2189,7 +2190,6 @@ GitLab has been tested on a number of object storage providers:
- [Oracle Cloud Infrastructure](https://docs.cloud.oracle.com/en-us/iaas/Content/Object/Tasks/s3compatibleapi.htm)
- [OpenStack Swift (S3 compatibility mode)](https://docs.openstack.org/swift/latest/s3_compat.html)
- [Azure Blob storage](https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blobs-introduction)
- On-premises hardware and appliances from various storage vendors.
- MinIO. We have [a guide to deploying this](https://docs.gitlab.com/charts/advanced/external-object-storage/minio.html) within our Helm Chart documentation.
There are two ways of specifying object storage configuration in GitLab:
@ -2199,25 +2199,13 @@ There are two ways of specifying object storage configuration in GitLab:
- [Storage-specific form](../object_storage.md#storage-specific-configuration): Every object defines its
own object storage [connection and configuration](../object_storage.md#connection-settings).
Starting with GitLab 13.2, consolidated object storage configuration is available. It simplifies your GitLab configuration since the connection details are shared across object types. Refer to [Consolidated object storage configuration](../object_storage.md#consolidated-object-storage-configuration) guide for instructions on how to set it up.
The consolidated form is used in the following examples when available.
For configuring object storage in GitLab 13.1 and earlier, or for storage types not
supported by consolidated configuration form, refer to the following guides based
on what features you intend to use:
|Object storage type|Supported by consolidated configuration?|
|-------------------|----------------------------------------|
| [Backups](../../raketasks/backup_gitlab.md#upload-backups-to-a-remote-cloud-storage) | No |
| [Job artifacts](../job_artifacts.md#using-object-storage) including archived job logs | Yes |
| [LFS objects](../lfs/index.md#storing-lfs-objects-in-remote-object-storage) | Yes |
| [Uploads](../uploads.md#using-object-storage) | Yes |
| [Container Registry](../packages/container_registry.md#use-object-storage) (optional feature) | No |
| [Merge request diffs](../merge_request_diffs.md#using-object-storage) | Yes |
| [Mattermost](https://docs.mattermost.com/administration/config-settings.html#file-storage)| No |
| [Packages](../packages/index.md#using-object-storage) (optional feature) | Yes |
| [Dependency Proxy](../packages/dependency_proxy.md#using-object-storage) (optional feature) | Yes |
| [Autoscale runner caching](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching) (optional for improved performance) | No |
| [Terraform state files](../terraform_state.md#using-object-storage) | Yes |
NOTE:
When using the [storage-specific form](../object_storage.md#storage-specific-configuration)
in GitLab 14.x and earlier, you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
The previous [background upload](../../development/uploads/index.md#direct-upload) mode,
which was deprecated in 14.9, requires shared storage such as [NFS](#configure-nfs-optional).
Using separate buckets for each data type is the recommended approach for GitLab.
This ensures there are no collisions across the various types of data GitLab stores.
@ -2230,12 +2218,28 @@ in the future.
</a>
</div>
## Enable incremental logging
### Enable incremental logging
GitLab Runner returns job logs in chunks which Omnibus GitLab caches temporarily on disk in `/var/opt/gitlab/gitlab-ci/builds` by default, even when using consolidated object storage. With default configuration, this directory needs to be shared through NFS on any GitLab Rails and Sidekiq nodes.
While sharing the job logs through NFS is supported, it's recommended to avoid the need to use NFS by enabling [incremental logging](../job_logs.md#incremental-logging-architecture) (required when no NFS node has been deployed). Incremental logging uses Redis instead of disk space for temporary caching of job logs.
## Configure NFS (optional)
[Object storage](#configure-the-object-storage), along with [Gitaly](#configure-gitaly)
are recommended over NFS wherever possible for improved performance.
See how to [configure NFS](../nfs.md).
WARNING:
Engineering support for NFS for Git repositories is deprecated, and [technical support is scheduled to be unavailable](../nfs.md#gitaly-and-nfs-deprecation)
after the release of GitLab 15.6. No further enhancements are planned for this feature.
Read:
- [Gitaly and NFS Deprecation](../nfs.md#gitaly-and-nfs-deprecation).
- About the [correct mount options to use](../nfs.md#upgrade-to-gitaly-cluster-or-disable-caching-if-experiencing-data-loss).
## Configure Advanced Search
You can leverage Elasticsearch and [enable Advanced Search](../../integration/advanced_search/elasticsearch.md)
@ -2252,28 +2256,6 @@ cluster alongside your instance, read how to
</a>
</div>
## Configure NFS
[Object storage](#configure-the-object-storage), along with [Gitaly](#configure-gitaly)
are recommended over NFS wherever possible for improved performance.
See how to [configure NFS](../nfs.md).
WARNING:
Engineering support for NFS for Git repositories is deprecated. Technical support is planned to be
unavailable from GitLab 15.0. No further enhancements are planned for this feature.
Read:
- [Gitaly and NFS Deprecation](../nfs.md#gitaly-and-nfs-deprecation).
- About the [correct mount options to use](../nfs.md#upgrade-to-gitaly-cluster-or-disable-caching-if-experiencing-data-loss).
<div align="right">
<a type="button" class="btn btn-default" href="#setup-components">
Back to setup components <i class="fa fa-angle-double-up" aria-hidden="true"></i>
</a>
</div>
## Cloud Native Hybrid reference architecture with Helm Charts (alternative)
As an alternative approach, you can also run select components of GitLab as Cloud Native

73
doc/administration/reference_architectures/25k_users.md
View File

@ -188,11 +188,11 @@ To set up GitLab and its components to accommodate up to 25,000 users:
environment.
1. [Configure the object storage](#configure-the-object-storage)
used for shared data objects.
1. [Configure NFS](#configure-nfs-optional) (optional, and not recommended)
to have shared disk storage service as an alternative to Gitaly or object
storage.
1. [Configure Advanced Search](#configure-advanced-search) (optional) for faster,
more advanced code search across your entire GitLab instance.
1. [Configure NFS](#configure-nfs)
to have shared disk storage service for certain GitLab operations (non
Gitaly or Object Storage).
The servers start on the same 10.6.0.0/24 private network range, and can
connect to each other freely on these addresses.
@ -2017,7 +2017,7 @@ On each node perform the following:
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. If you're [using NFS](#configure-nfs):
1. If you're [using NFS](#configure-nfs-optional):
1. If necessary, install the NFS client utility packages using the following
commands:
@ -2181,9 +2181,9 @@ To configure the Monitoring node:
## Configure the object storage
GitLab supports using an object storage service for holding numerous types of data.
Object storage is also recommended over [NFS](#configure-nfs) and in general
it's better in larger setups as object storage is typically much more performant,
reliable, and scalable.
It's recommended over [NFS](#configure-nfs-optional) and in general it's better
in larger setups as object storage is typically much more performant, reliable,
and scalable.
GitLab has been tested on a number of object storage providers:
@ -2193,7 +2193,6 @@ GitLab has been tested on a number of object storage providers:
- [Oracle Cloud Infrastructure](https://docs.cloud.oracle.com/en-us/iaas/Content/Object/Tasks/s3compatibleapi.htm)
- [OpenStack Swift (S3 compatibility mode)](https://docs.openstack.org/swift/latest/s3_compat.html)
- [Azure Blob storage](https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blobs-introduction)
- On-premises hardware and appliances from various storage vendors.
- MinIO. We have [a guide to deploying this](https://docs.gitlab.com/charts/advanced/external-object-storage/minio.html) within our Helm Chart documentation.
There are two ways of specifying object storage configuration in GitLab:
@ -2203,25 +2202,13 @@ There are two ways of specifying object storage configuration in GitLab:
- [Storage-specific form](../object_storage.md#storage-specific-configuration): Every object defines its
own object storage [connection and configuration](../object_storage.md#connection-settings).
Starting with GitLab 13.2, consolidated object storage configuration is available. It simplifies your GitLab configuration since the connection details are shared across object types. Refer to [Consolidated object storage configuration](../object_storage.md#consolidated-object-storage-configuration) guide for instructions on how to set it up.
The consolidated form is used in the following examples when available.
For configuring object storage in GitLab 13.1 and earlier, or for storage types not
supported by consolidated configuration form, refer to the following guides based
on what features you intend to use:
|Object storage type|Supported by consolidated configuration?|
|-------------------|----------------------------------------|
| [Backups](../../raketasks/backup_gitlab.md#upload-backups-to-a-remote-cloud-storage) | No |
| [Job artifacts](../job_artifacts.md#using-object-storage) including archived job logs | Yes |
| [LFS objects](../lfs/index.md#storing-lfs-objects-in-remote-object-storage) | Yes |
| [Uploads](../uploads.md#using-object-storage) | Yes |
| [Container Registry](../packages/container_registry.md#use-object-storage) (optional feature) | No |
| [Merge request diffs](../merge_request_diffs.md#using-object-storage) | Yes |
| [Mattermost](https://docs.mattermost.com/administration/config-settings.html#file-storage)| No |
| [Packages](../packages/index.md#using-object-storage) (optional feature) | Yes |
| [Dependency Proxy](../packages/dependency_proxy.md#using-object-storage) (optional feature) | Yes |
| [Autoscale runner caching](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching) (optional for improved performance) | No |
| [Terraform state files](../terraform_state.md#using-object-storage) | Yes |
NOTE:
When using the [storage-specific form](../object_storage.md#storage-specific-configuration)
in GitLab 14.x and earlier, you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
The previous [background upload](../../development/uploads/index.md#direct-upload) mode,
which was deprecated in 14.9, requires shared storage such as [NFS](#configure-nfs-optional).
Using separate buckets for each data type is the recommended approach for GitLab.
This ensures there are no collisions across the various types of data GitLab stores.
@ -2234,12 +2221,28 @@ in the future.
</a>
</div>
## Enable incremental logging
### Enable incremental logging
GitLab Runner returns job logs in chunks which Omnibus GitLab caches temporarily on disk in `/var/opt/gitlab/gitlab-ci/builds` by default, even when using consolidated object storage. With default configuration, this directory needs to be shared through NFS on any GitLab Rails and Sidekiq nodes.
While sharing the job logs through NFS is supported, it's recommended to avoid the need to use NFS by enabling [incremental logging](../job_logs.md#incremental-logging-architecture) (required when no NFS node has been deployed). Incremental logging uses Redis instead of disk space for temporary caching of job logs.
## Configure NFS (optional)
[Object storage](#configure-the-object-storage), along with [Gitaly](#configure-gitaly)
are recommended over NFS wherever possible for improved performance.
See how to [configure NFS](../nfs.md).
WARNING:
Engineering support for NFS for Git repositories is deprecated, and [technical support is scheduled to be unavailable](../nfs.md#gitaly-and-nfs-deprecation)
after the release of GitLab 15.6. No further enhancements are planned for this feature.
Read:
- [Gitaly and NFS Deprecation](../nfs.md#gitaly-and-nfs-deprecation).
- About the [correct mount options to use](../nfs.md#upgrade-to-gitaly-cluster-or-disable-caching-if-experiencing-data-loss).
## Configure Advanced Search
You can leverage Elasticsearch and [enable Advanced Search](../../integration/advanced_search/elasticsearch.md)
@ -2256,22 +2259,6 @@ cluster alongside your instance, read how to
</a>
</div>
## Configure NFS
[Object storage](#configure-the-object-storage), along with [Gitaly](#configure-gitaly)
are recommended over NFS wherever possible for improved performance.
See how to [configure NFS](../nfs.md).
WARNING:
Engineering support for NFS for Git repositories is deprecated. Technical support is planned to be
unavailable from GitLab 15.0. No further enhancements are planned for this feature.
Read:
- [Gitaly and NFS Deprecation](../nfs.md#gitaly-and-nfs-deprecation).
- About the [correct mount options to use](../nfs.md#upgrade-to-gitaly-cluster-or-disable-caching-if-experiencing-data-loss).
## Cloud Native Hybrid reference architecture with Helm Charts (alternative)
As an alternative approach, you can also run select components of GitLab as Cloud Native

81
doc/administration/reference_architectures/2k_users.md
View File

@ -112,11 +112,11 @@ To set up GitLab and its components to accommodate up to 2,000 users:
environment.
1. [Configure the object storage](#configure-the-object-storage) used for
shared data objects.
1. [Configure Advanced Search](#configure-advanced-search) (optional) for faster,
more advanced code search across your entire GitLab instance.
1. [Configure NFS](#configure-nfs-optional) (optional, and not recommended)
to have shared disk storage service as an alternative to Gitaly or object
storage.
1. [Configure Advanced Search](#configure-advanced-search) (optional) for faster,
more advanced code search across your entire GitLab instance.
## Configure the external load balancer
@ -887,10 +887,10 @@ running [Prometheus](../monitoring/prometheus/index.md) and
## Configure the object storage
GitLab supports using an object storage service for holding several types of
data, and is recommended over [NFS](#configure-nfs-optional). In general,
object storage services are better for larger environments, as object storage
is typically much more performant, reliable, and scalable.
GitLab supports using an object storage service for holding numerous types of data.
It's recommended over [NFS](#configure-nfs-optional) and in general it's better
in larger setups as object storage is typically much more performant, reliable,
and scalable.
GitLab has been tested on a number of object storage providers:
@ -900,7 +900,6 @@ GitLab has been tested on a number of object storage providers:
- [Oracle Cloud Infrastructure](https://docs.cloud.oracle.com/en-us/iaas/Content/Object/Tasks/s3compatibleapi.htm)
- [OpenStack Swift (S3 compatibility mode)](https://docs.openstack.org/swift/latest/s3_compat.html)
- [Azure Blob storage](https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blobs-introduction)
- On-premises hardware and appliances from various storage vendors.
- MinIO. We have [a guide to deploying this](https://docs.gitlab.com/charts/advanced/external-object-storage/minio.html) within our Helm Chart documentation.
There are two ways of specifying object storage configuration in GitLab:
@ -910,29 +909,13 @@ There are two ways of specifying object storage configuration in GitLab:
- [Storage-specific form](../object_storage.md#storage-specific-configuration): Every object defines its
own object storage [connection and configuration](../object_storage.md#connection-settings).
Starting with GitLab 13.2, consolidated object storage configuration is available. It simplifies your GitLab configuration since the connection details are shared across object types. Refer to [Consolidated object storage configuration](../object_storage.md#consolidated-object-storage-configuration) guide for instructions on how to set it up.
The consolidated form is used in the following examples when available.
GitLab Runner returns job logs in chunks which Omnibus GitLab caches temporarily on disk in `/var/opt/gitlab/gitlab-ci/builds` by default, even when using consolidated object storage. With default configuration, this directory needs to be shared via NFS on any GitLab Rails and Sidekiq nodes.
In GitLab 13.6 and later, it's also recommended to switch to [Incremental logging](../job_logs.md#incremental-logging-architecture), which uses Redis instead of disk space for temporary caching of job logs. This is required when no NFS node has been deployed.
For configuring object storage in GitLab 13.1 and earlier, or for storage types not
supported by consolidated configuration form, refer to the following guides based
on what features you intend to use:
|Object storage type|Supported by consolidated configuration?|
|-------------------|----------------------------------------|
| [Backups](../../raketasks/backup_gitlab.md#upload-backups-to-a-remote-cloud-storage) | No |
| [Job artifacts](../job_artifacts.md#using-object-storage) including archived job logs | Yes |
| [LFS objects](../lfs/index.md#storing-lfs-objects-in-remote-object-storage) | Yes |
| [Uploads](../uploads.md#using-object-storage) | Yes |
| [Container Registry](../packages/container_registry.md#use-object-storage) (optional feature) | No |
| [Merge request diffs](../merge_request_diffs.md#using-object-storage) | Yes |
| [Mattermost](https://docs.mattermost.com/administration/config-settings.html#file-storage)| No |
| [Packages](../packages/index.md#using-object-storage) (optional feature) | Yes |
| [Dependency Proxy](../packages/dependency_proxy.md#using-object-storage) (optional feature) | Yes |
| [Autoscale runner caching](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching) (optional for improved performance) | No |
| [Terraform state files](../terraform_state.md#using-object-storage) | Yes |
NOTE:
When using the [storage-specific form](../object_storage.md#storage-specific-configuration)
in GitLab 14.x and earlier, you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
The previous [background upload](../../development/uploads/index.md#direct-upload) mode,
which was deprecated in 14.9, requires shared storage such as [NFS](#configure-nfs-optional).
Using separate buckets for each data type is the recommended approach for GitLab.
This ensures there are no collisions across the various types of data GitLab stores.
@ -945,6 +928,29 @@ in the future.
</a>
</div>
### Enable incremental logging
GitLab Runner returns job logs in chunks which Omnibus GitLab caches temporarily on disk in `/var/opt/gitlab/gitlab-ci/builds` by default, even when using consolidated object storage. With default configuration, this directory needs to be shared through NFS on any GitLab Rails and Sidekiq nodes.
While sharing the job logs through NFS is supported, it's recommended to avoid the need to use NFS by enabling [incremental logging](../job_logs.md#incremental-logging-architecture) (required when no NFS node has been deployed). Incremental logging uses Redis instead of disk space for temporary caching of job logs.
## Configure NFS (optional)
For improved performance, [object storage](#configure-the-object-storage),
along with [Gitaly](#configure-gitaly), are recommended over using NFS whenever
possible.
See how to [configure NFS](../nfs.md).
WARNING:
Engineering support for NFS for Git repositories is deprecated, and [technical support is scheduled to be unavailable](../nfs.md#gitaly-and-nfs-deprecation)
after the release of GitLab 15.6. No further enhancements are planned for this feature.
Read:
- [Gitaly and NFS Deprecation](../nfs.md#gitaly-and-nfs-deprecation).
- About the [correct mount options to use](../nfs.md#upgrade-to-gitaly-cluster-or-disable-caching-if-experiencing-data-loss).
## Configure Advanced Search **(PREMIUM SELF)**
You can leverage Elasticsearch and [enable Advanced Search](../../integration/advanced_search/elasticsearch.md)
@ -961,23 +967,6 @@ cluster alongside your instance, read how to
</a>
</div>
## Configure NFS (optional)
For improved performance, [object storage](#configure-the-object-storage),
along with [Gitaly](#configure-gitaly), are recommended over using NFS whenever
possible.
See how to [configure NFS](../nfs.md).
WARNING:
Engineering support for NFS for Git repositories is deprecated. Technical support is planned to be
unavailable from GitLab 15.0. No further enhancements are planned for this feature.
Read:
- [Gitaly and NFS Deprecation](../nfs.md#gitaly-and-nfs-deprecation).
- About the [correct mount options to use](../nfs.md#upgrade-to-gitaly-cluster-or-disable-caching-if-experiencing-data-loss).
## Cloud Native Hybrid reference architecture with Helm Charts (alternative)
As an alternative approach, you can also run select components of GitLab as Cloud Native

63
doc/administration/reference_architectures/3k_users.md
View File

@ -194,11 +194,11 @@ To set up GitLab and its components to accommodate up to 3,000 users:
environment.
1. [Configure the object storage](#configure-the-object-storage)
used for shared data objects.
1. [Configure Advanced Search](#configure-advanced-search) (optional) for faster,
more advanced code search across your entire GitLab instance.
1. [Configure NFS](#configure-nfs-optional) (optional, and not recommended)
to have shared disk storage service as an alternative to Gitaly or object
storage.
1. [Configure Advanced Search](#configure-advanced-search) (optional) for faster,
more advanced code search across your entire GitLab instance.
The servers start on the same 10.6.0.0/24 private network range, and can
connect to each other freely on these addresses.
@ -2130,7 +2130,6 @@ GitLab has been tested on a number of object storage providers:
- [Oracle Cloud Infrastructure](https://docs.cloud.oracle.com/en-us/iaas/Content/Object/Tasks/s3compatibleapi.htm)
- [OpenStack Swift (S3 compatibility mode)](https://docs.openstack.org/swift/latest/s3_compat.html)
- [Azure Blob storage](https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blobs-introduction)
- On-premises hardware and appliances from various storage vendors.
- MinIO. We have [a guide to deploying this](https://docs.gitlab.com/charts/advanced/external-object-storage/minio.html) within our Helm Chart documentation.
There are two ways of specifying object storage configuration in GitLab:
@ -2140,25 +2139,13 @@ There are two ways of specifying object storage configuration in GitLab:
- [Storage-specific form](../object_storage.md#storage-specific-configuration): Every object defines its
own object storage [connection and configuration](../object_storage.md#connection-settings).
Starting with GitLab 13.2, consolidated object storage configuration is available. It simplifies your GitLab configuration since the connection details are shared across object types. Refer to [Consolidated object storage configuration](../object_storage.md#consolidated-object-storage-configuration) guide for instructions on how to set it up.
The consolidated form is used in the following examples when available.
For configuring object storage in GitLab 13.1 and earlier, or for storage types not
supported by consolidated configuration form, refer to the following guides based
on what features you intend to use:
|Object storage type|Supported by consolidated configuration?|
|-------------------|----------------------------------------|
| [Backups](../../raketasks/backup_gitlab.md#upload-backups-to-a-remote-cloud-storage) | No |
| [Job artifacts](../job_artifacts.md#using-object-storage) including archived job logs | Yes |
| [LFS objects](../lfs/index.md#storing-lfs-objects-in-remote-object-storage) | Yes |
| [Uploads](../uploads.md#using-object-storage) | Yes |
| [Container Registry](../packages/container_registry.md#use-object-storage) (optional feature) | No |
| [Merge request diffs](../merge_request_diffs.md#using-object-storage) | Yes |
| [Mattermost](https://docs.mattermost.com/administration/config-settings.html#file-storage)| No |
| [Packages](../packages/index.md#using-object-storage) (optional feature) | Yes |
| [Dependency Proxy](../packages/dependency_proxy.md#using-object-storage) (optional feature) | Yes |
| [Autoscale runner caching](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching) (optional for improved performance) | No |
| [Terraform state files](../terraform_state.md#using-object-storage) | Yes |
NOTE:
When using the [storage-specific form](../object_storage.md#storage-specific-configuration)
in GitLab 14.x and earlier, you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
The previous [background upload](../../development/uploads/index.md#direct-upload) mode,
which was deprecated in 14.9, requires shared storage such as [NFS](#configure-nfs-optional).
Using separate buckets for each data type is the recommended approach for GitLab.
This ensures there are no collisions across the various types of data GitLab stores.
@ -2171,12 +2158,28 @@ in the future.
</a>
</div>
## Enable incremental logging
### Enable incremental logging
GitLab Runner returns job logs in chunks which Omnibus GitLab caches temporarily on disk in `/var/opt/gitlab/gitlab-ci/builds` by default, even when using consolidated object storage. With default configuration, this directory needs to be shared through NFS on any GitLab Rails and Sidekiq nodes.
While sharing the job logs through NFS is supported, it's recommended to avoid the need to use NFS by enabling [incremental logging](../job_logs.md#incremental-logging-architecture) (required when no NFS node has been deployed). Incremental logging uses Redis instead of disk space for temporary caching of job logs.
## Configure NFS (optional)
[Object storage](#configure-the-object-storage), along with [Gitaly](#configure-gitaly)
are recommended over NFS wherever possible for improved performance.
See how to [configure NFS](../nfs.md).
WARNING:
Engineering support for NFS for Git repositories is deprecated, and [technical support is scheduled to be unavailable](../nfs.md#gitaly-and-nfs-deprecation)
after the release of GitLab 15.6. No further enhancements are planned for this feature.
Read:
- [Gitaly and NFS Deprecation](../nfs.md#gitaly-and-nfs-deprecation).
- About the [correct mount options to use](../nfs.md#upgrade-to-gitaly-cluster-or-disable-caching-if-experiencing-data-loss).
## Configure Advanced Search
You can leverage Elasticsearch and [enable Advanced Search](../../integration/advanced_search/elasticsearch.md)
@ -2193,22 +2196,6 @@ cluster alongside your instance, read how to
</a>
</div>
## Configure NFS (optional)
[Object storage](#configure-the-object-storage), along with [Gitaly](#configure-gitaly)
are recommended over NFS wherever possible for improved performance.
See how to [configure NFS](../nfs.md).
WARNING:
Engineering support for NFS for Git repositories is deprecated. Technical support is planned to be
unavailable from GitLab 15.0. No further enhancements are planned for this feature.
Read:
- [Gitaly and NFS Deprecation](../nfs.md#gitaly-and-nfs-deprecation).
- About the [correct mount options to use](../nfs.md#upgrade-to-gitaly-cluster-or-disable-caching-if-experiencing-data-loss).
## Supported modifications for lower user counts (HA)
The 3k GitLab reference architecture is the smallest we recommend that achieves High Availability (HA).

68
doc/administration/reference_architectures/50k_users.md
View File

@ -188,10 +188,11 @@ To set up GitLab and its components to accommodate up to 50,000 users:
environment.
1. [Configure the object storage](#configure-the-object-storage)
used for shared data objects.
1. [Configure NFS](#configure-nfs-optional) (optional, and not recommended)
to have shared disk storage service as an alternative to Gitaly or object
storage.
1. [Configure Advanced Search](#configure-advanced-search) (optional) for faster,
more advanced code search across your entire GitLab instance.
1. [Configure NFS](#configure-nfs)
to have shared disk storage service for certain GitLab operations (non Gitaly or Object Storage).
The servers start on the same 10.6.0.0/24 private network range, and can
connect to each other freely on these addresses.
@ -2033,7 +2034,7 @@ On each node perform the following:
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. If you're [using NFS](#configure-nfs):
1. If you're [using NFS](#configure-nfs-optional):
1. If necessary, install the NFS client utility packages using the following
commands:
@ -2197,7 +2198,7 @@ To configure the Monitoring node:
## Configure the object storage
GitLab supports using an object storage service for holding numerous types of data.
It's recommended over [NFS](#configure-nfs) and in general it's better
It's recommended over [NFS](#configure-nfs-optional) and in general it's better
in larger setups as object storage is typically much more performant, reliable,
and scalable.
@ -2209,7 +2210,6 @@ GitLab has been tested on a number of object storage providers:
- [Oracle Cloud Infrastructure](https://docs.cloud.oracle.com/en-us/iaas/Content/Object/Tasks/s3compatibleapi.htm)
- [OpenStack Swift (S3 compatibility mode)](https://docs.openstack.org/swift/latest/s3_compat.html)
- [Azure Blob storage](https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blobs-introduction)
- On-premises hardware and appliances from various storage vendors.
- MinIO. We have [a guide to deploying this](https://docs.gitlab.com/charts/advanced/external-object-storage/minio.html) within our Helm Chart documentation.
There are two ways of specifying object storage configuration in GitLab:
@ -2219,25 +2219,13 @@ There are two ways of specifying object storage configuration in GitLab:
- [Storage-specific form](../object_storage.md#storage-specific-configuration): Every object defines its
own object storage [connection and configuration](../object_storage.md#connection-settings).
Starting with GitLab 13.2, consolidated object storage configuration is available. It simplifies your GitLab configuration since the connection details are shared across object types. Refer to [Consolidated object storage configuration](../object_storage.md#consolidated-object-storage-configuration) guide for instructions on how to set it up.
The consolidated form is used in the following examples when available.
For configuring object storage in GitLab 13.1 and earlier, or for storage types not
supported by consolidated configuration form, refer to the following guides based
on what features you intend to use:
|Object storage type|Supported by consolidated configuration?|
|-------------------|----------------------------------------|
| [Backups](../../raketasks/backup_gitlab.md#upload-backups-to-a-remote-cloud-storage) | No |
| [Job artifacts](../job_artifacts.md#using-object-storage) including archived job logs | Yes |
| [LFS objects](../lfs/index.md#storing-lfs-objects-in-remote-object-storage) | Yes |
| [Uploads](../uploads.md#using-object-storage) | Yes |
| [Container Registry](../packages/container_registry.md#use-object-storage) (optional feature) | No |
| [Merge request diffs](../merge_request_diffs.md#using-object-storage) | Yes |
| [Mattermost](https://docs.mattermost.com/administration/config-settings.html#file-storage)| No |
| [Packages](../packages/index.md#using-object-storage) (optional feature) | Yes |
| [Dependency Proxy](../packages/dependency_proxy.md#using-object-storage) (optional feature) | Yes |
| [Autoscale runner caching](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching) (optional for improved performance) | No |
| [Terraform state files](../terraform_state.md#using-object-storage) | Yes |
NOTE:
When using the [storage-specific form](../object_storage.md#storage-specific-configuration)
in GitLab 14.x and earlier, you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
The previous [background upload](../../development/uploads/index.md#direct-upload) mode,
which was deprecated in 14.9, requires shared storage such as [NFS](#configure-nfs-optional).
Using separate buckets for each data type is the recommended approach for GitLab.
This ensures there are no collisions across the various types of data GitLab stores.
@ -2250,12 +2238,28 @@ in the future.
</a>
</div>
## Enable incremental logging
### Enable incremental logging
GitLab Runner returns job logs in chunks which Omnibus GitLab caches temporarily on disk in `/var/opt/gitlab/gitlab-ci/builds` by default, even when using consolidated object storage. With default configuration, this directory needs to be shared through NFS on any GitLab Rails and Sidekiq nodes.
While sharing the job logs through NFS is supported, it's recommended to avoid the need to use NFS by enabling [incremental logging](../job_logs.md#incremental-logging-architecture) (required when no NFS node has been deployed). Incremental logging uses Redis instead of disk space for temporary caching of job logs.
## Configure NFS (optional)
[Object storage](#configure-the-object-storage), along with [Gitaly](#configure-gitaly)
are recommended over NFS wherever possible for improved performance.
See how to [configure NFS](../nfs.md).
WARNING:
Engineering support for NFS for Git repositories is deprecated, and [technical support is scheduled to be unavailable](../nfs.md#gitaly-and-nfs-deprecation)
after the release of GitLab 15.6. No further enhancements are planned for this feature.
Read:
- [Gitaly and NFS Deprecation](../nfs.md#gitaly-and-nfs-deprecation).
- About the [correct mount options to use](../nfs.md#upgrade-to-gitaly-cluster-or-disable-caching-if-experiencing-data-loss).
## Configure Advanced Search
You can leverage Elasticsearch and [enable Advanced Search](../../integration/advanced_search/elasticsearch.md)
@ -2272,22 +2276,6 @@ cluster alongside your instance, read how to
</a>
</div>
## Configure NFS
[Object storage](#configure-the-object-storage), along with [Gitaly](#configure-gitaly)
are recommended over NFS wherever possible for improved performance.
See how to [configure NFS](../nfs.md).
WARNING:
Engineering support for NFS for Git repositories is deprecated. Technical support is planned to be
unavailable from GitLab 15.0. No further enhancements are planned for this feature.
Read:
- [Gitaly and NFS Deprecation](../nfs.md#gitaly-and-nfs-deprecation).
- About the [correct mount options to use](../nfs.md#upgrade-to-gitaly-cluster-or-disable-caching-if-experiencing-data-loss).
## Cloud Native Hybrid reference architecture with Helm Charts (alternative)
As an alternative approach, you can also run select components of GitLab as Cloud Native

66
doc/administration/reference_architectures/5k_users.md
View File

@ -191,12 +191,11 @@ To set up GitLab and its components to accommodate up to 5,000 users:
environment.
1. [Configure the object storage](#configure-the-object-storage)
used for shared data objects.
1. [Configure Advanced Search](#configure-advanced-search) (optional) for faster,
more advanced code search across your entire GitLab instance.
1. [Configure NFS](#configure-nfs-optional) (optional, and not recommended)
to have shared disk storage service as an alternative to Gitaly or object
storage. You can skip this step if you're not using GitLab Pages (which
requires NFS).
storage.
1. [Configure Advanced Search](#configure-advanced-search) (optional) for faster,
more advanced code search across your entire GitLab instance.
The servers start on the same 10.6.0.0/24 private network range, and can
connect to each other freely on these addresses.
@ -2130,7 +2129,6 @@ GitLab has been tested on a number of object storage providers:
- [Oracle Cloud Infrastructure](https://docs.cloud.oracle.com/en-us/iaas/Content/Object/Tasks/s3compatibleapi.htm)
- [OpenStack Swift (S3 compatibility mode)](https://docs.openstack.org/swift/latest/s3_compat.html)
- [Azure Blob storage](https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blobs-introduction)
- On-premises hardware and appliances from various storage vendors.
- MinIO. We have [a guide to deploying this](https://docs.gitlab.com/charts/advanced/external-object-storage/minio.html) within our Helm Chart documentation.
There are two ways of specifying object storage configuration in GitLab:
@ -2140,25 +2138,13 @@ There are two ways of specifying object storage configuration in GitLab:
- [Storage-specific form](../object_storage.md#storage-specific-configuration): Every object defines its
own object storage [connection and configuration](../object_storage.md#connection-settings).
Starting with GitLab 13.2, consolidated object storage configuration is available. It simplifies your GitLab configuration since the connection details are shared across object types. Refer to [Consolidated object storage configuration](../object_storage.md#consolidated-object-storage-configuration) guide for instructions on how to set it up.
The consolidated form is used in the following examples when available.
For configuring object storage in GitLab 13.1 and earlier, or for storage types not
supported by consolidated configuration form, refer to the following guides based
on what features you intend to use:
|Object storage type|Supported by consolidated configuration?|
|-------------------|----------------------------------------|
| [Backups](../../raketasks/backup_gitlab.md#upload-backups-to-a-remote-cloud-storage) | No |
| [Job artifacts](../job_artifacts.md#using-object-storage) including archived job logs | Yes |
| [LFS objects](../lfs/index.md#storing-lfs-objects-in-remote-object-storage) | Yes |
| [Uploads](../uploads.md#using-object-storage) | Yes |
| [Container Registry](../packages/container_registry.md#use-object-storage) (optional feature) | No |
| [Merge request diffs](../merge_request_diffs.md#using-object-storage) | Yes |
| [Mattermost](https://docs.mattermost.com/administration/config-settings.html#file-storage)| No |
| [Packages](../packages/index.md#using-object-storage) (optional feature) | Yes |
| [Dependency Proxy](../packages/dependency_proxy.md#using-object-storage) (optional feature) | Yes |
| [Autoscale runner caching](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching) (optional for improved performance) | No |
| [Terraform state files](../terraform_state.md#using-object-storage) | Yes |
NOTE:
When using the [storage-specific form](../object_storage.md#storage-specific-configuration)
in GitLab 14.x and earlier, you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
The previous [background upload](../../development/uploads/index.md#direct-upload) mode,
which was deprecated in 14.9, requires shared storage such as [NFS](#configure-nfs-optional).
Using separate buckets for each data type is the recommended approach for GitLab.
This ensures there are no collisions across the various types of data GitLab stores.
@ -2171,12 +2157,28 @@ in the future.
</a>
</div>
## Enable incremental logging
### Enable incremental logging
GitLab Runner returns job logs in chunks which Omnibus GitLab caches temporarily on disk in `/var/opt/gitlab/gitlab-ci/builds` by default, even when using consolidated object storage. With default configuration, this directory needs to be shared through NFS on any GitLab Rails and Sidekiq nodes.
While sharing the job logs through NFS is supported, it's recommended to avoid the need to use NFS by enabling [incremental logging](../job_logs.md#incremental-logging-architecture) (required when no NFS node has been deployed). Incremental logging uses Redis instead of disk space for temporary caching of job logs.
## Configure NFS (optional)
[Object storage](#configure-the-object-storage), along with [Gitaly](#configure-gitaly)
are recommended over NFS wherever possible for improved performance.
See how to [configure NFS](../nfs.md).
WARNING:
Engineering support for NFS for Git repositories is deprecated, and [technical support is scheduled to be unavailable](../nfs.md#gitaly-and-nfs-deprecation)
after the release of GitLab 15.6. No further enhancements are planned for this feature.
Read:
- [Gitaly and NFS Deprecation](../nfs.md#gitaly-and-nfs-deprecation).
- About the [correct mount options to use](../nfs.md#upgrade-to-gitaly-cluster-or-disable-caching-if-experiencing-data-loss).
## Configure Advanced Search
You can leverage Elasticsearch and [enable Advanced Search](../../integration/advanced_search/elasticsearch.md)
@ -2193,22 +2195,6 @@ cluster alongside your instance, read how to
</a>
</div>
## Configure NFS (optional)
[Object storage](#configure-the-object-storage), along with [Gitaly](#configure-gitaly)
are recommended over NFS wherever possible for improved performance.
See how to [configure NFS](../nfs.md).
WARNING:
Engineering support for NFS for Git repositories is deprecated. Technical support is planned to be
unavailable from GitLab 15.0. No further enhancements are planned for this feature.
Read:
- [Gitaly and NFS Deprecation](../nfs.md#gitaly-and-nfs-deprecation).
- About the [correct mount options to use](../nfs.md#upgrade-to-gitaly-cluster-or-disable-caching-if-experiencing-data-loss).
## Cloud Native Hybrid reference architecture with Helm Charts (alternative)
As an alternative approach, you can also run select components of GitLab as Cloud Native

7
doc/update/package/index.md
View File

@ -330,3 +330,10 @@ To fix this error:
```shell
sudo gitlab-ctl reconfigure
```
1. Hot reload `puma` and `sidekiq` services:
```shell
sudo gitlab-ctl hup puma
sudo gitlab-ctl restart sidekiq
```

6
locale/gitlab.pot
View File

@ -2294,6 +2294,9 @@ msgstr ""
msgid "Add label(s)"
msgstr ""
msgid "Add labels"
msgstr ""
msgid "Add license"
msgstr ""
@ -13473,6 +13476,9 @@ msgstr ""
msgid "DevOps adoption"
msgstr ""
msgid "Development"
msgstr ""
msgid "Devices (optional)"
msgstr ""

33
spec/controllers/help_controller_spec.rb
View File

@ -139,6 +139,39 @@ RSpec.describe HelpController do
end
end
describe 'GET #drawers' do
subject { get :drawers, params: { markdown_file: path } }
context 'when requested file exists' do
let(:path) { 'user/ssh' }
let(:file_name) { "#{path}.md" }
before do
subject
end
it 'assigns variables', :aggregate_failures do
expect(assigns[:path]).not_to be_empty
expect(assigns[:clean_path]).not_to be_empty
end
it 'renders HTML', :aggregate_failures do
is_expected.to render_template('help/drawers')
expect(response.media_type).to eq 'text/html'
end
end
context 'when requested file is missing' do
let(:path) { 'foo/bar' }
it 'renders not found' do
subject
expect(response).to be_not_found
end
end
end
describe 'GET #show' do
context 'for Markdown formats' do
subject { get :show, params: { path: path }, format: :md }

26
spec/frontend/issuable/issuable_form_spec.js
View File

@ -84,6 +84,20 @@ describe('IssuableForm', () => {
'autosave//issues/new/bar=true=description',
);
});
it('creates due_date autosave when due_date input exist', () => {
$form.append(`<input type="text" name="issue[due_date]"/>`);
const $dueDate = $form.find(`input[name*="[due_date]"]`);
const totalAutosaveFormFields = $form.children().length;
createIssuable($form);
expect(Autosave).toHaveBeenCalledTimes(totalAutosaveFormFields);
expect(Autosave).toHaveBeenLastCalledWith(
$dueDate,
['/', '', 'due_date'],
`autosave///=due_date`,
);
});
});
describe('resetAutosave', () => {
@ -92,8 +106,8 @@ describe('IssuableForm', () => {
instance.resetAutosave();
expect(instance.autosaveTitle.reset).toHaveBeenCalledTimes(1);
expect(instance.autosaveDescription.reset).toHaveBeenCalledTimes(1);
expect(instance.autosaves.get('title').reset).toHaveBeenCalledTimes(1);
expect(instance.autosaves.get('description').reset).toHaveBeenCalledTimes(1);
});
it('resets autosave when submit', () => {
@ -114,6 +128,14 @@ describe('IssuableForm', () => {
expect(resetAutosave).toHaveBeenCalledTimes(1);
});
it('creates due_date autosave when due_date input exist', () => {
$form.append(`<input type="text" name="issue[due_date]"/>`);
instance = createIssuable($form);
instance.resetAutosave();
expect(instance.autosaves.get('due_date').reset).toHaveBeenCalledTimes(1);
});
});
});

3
spec/frontend/pipeline_editor/pipeline_editor_app_spec.js
View File

@ -149,8 +149,7 @@ describe('Pipeline editor app component', () => {
const findAlert = () => wrapper.findComponent(GlAlert);
const findEditorHome = () => wrapper.findComponent(PipelineEditorHome);
const findEmptyState = () => wrapper.findComponent(PipelineEditorEmptyState);
const findEmptyStateButton = () =>
wrapper.findComponent(PipelineEditorEmptyState).findComponent(GlButton);
const findEmptyStateButton = () => findEmptyState().findComponent(GlButton);
const findValidationSegment = () => wrapper.findComponent(ValidationSegment);
beforeEach(() => {

32
spec/helpers/jira_connect_helper_spec.rb
View File

@ -4,7 +4,8 @@ require 'spec_helper'
RSpec.describe JiraConnectHelper do
describe '#jira_connect_app_data' do
let_it_be(:subscription) { create(:jira_connect_subscription) }
let_it_be(:installation) { create(:jira_connect_installation) }
let_it_be(:subscription) { create(:jira_connect_subscription, installation: installation) }
let(:user) { create(:user) }
let(:client_id) { '123' }
@ -13,11 +14,12 @@ RSpec.describe JiraConnectHelper do
stub_application_setting(jira_connect_application_key: client_id)
end
subject { helper.jira_connect_app_data([subscription]) }
subject { helper.jira_connect_app_data([subscription], installation) }
context 'user is not logged in' do
before do
allow(view).to receive(:current_user).and_return(nil)
allow(Gitlab).to receive_message_chain('config.gitlab.host') { 'http://test.host' }
end
it 'includes Jira Connect app attributes' do
@ -36,7 +38,7 @@ RSpec.describe JiraConnectHelper do
end
context 'with oauth_metadata' do
let(:oauth_metadata) { helper.jira_connect_app_data([subscription])[:oauth_metadata] }
let(:oauth_metadata) { helper.jira_connect_app_data([subscription], installation)[:oauth_metadata] }
subject(:parsed_oauth_metadata) { Gitlab::Json.parse(oauth_metadata).deep_symbolize_keys }
@ -74,6 +76,30 @@ RSpec.describe JiraConnectHelper do
expect(oauth_metadata).to be_nil
end
end
context 'with self-managed instance' do
let_it_be(:installation) { create(:jira_connect_installation, instance_url: 'https://gitlab.example.com') }
it 'points urls to the self-managed instance' do
expect(parsed_oauth_metadata).to include(
oauth_authorize_url: start_with('https://gitlab.example.com/oauth/authorize?'),
oauth_token_url: 'https://gitlab.example.com/oauth/token'
)
end
context 'and jira_connect_oauth_self_managed feature is disabled' do
before do
stub_feature_flags(jira_connect_oauth_self_managed: false)
end
it 'does not point urls to the self-managed instance' do
expect(parsed_oauth_metadata).not_to include(
oauth_authorize_url: start_with('https://gitlab.example.com/oauth/authorize?'),
oauth_token_url: 'https://gitlab.example.com/oauth/token'
)
end
end
end
end
it 'passes group as "skip_groups" param' do

26
spec/models/jira_connect_installation_spec.rb
View File

@ -45,4 +45,30 @@ RSpec.describe JiraConnectInstallation do
expect(subject).to contain_exactly(subscription.installation)
end
end
describe '#oauth_authorization_url' do
let_it_be(:installation) { create(:jira_connect_installation) }
subject { installation.oauth_authorization_url }
before do
allow(Gitlab).to receive_message_chain('config.gitlab.host') { 'http://test.host' }
end
it { is_expected.to eq('http://test.host') }
context 'with instance_url' do
let_it_be(:installation) { create(:jira_connect_installation, instance_url: 'https://gitlab.example.com') }
it { is_expected.to eq('https://gitlab.example.com') }
context 'and jira_connect_oauth_self_managed feature is disabled' do
before do
stub_feature_flags(jira_connect_oauth_self_managed: false)
end
it { is_expected.to eq('http://test.host') }
end
end
end
end

18
spec/views/help/drawers.html.haml_spec.rb Normal file
View File

@ -0,0 +1,18 @@
# frozen_string_literal: true
require 'spec_helper'
RSpec.describe 'help/drawers' do
describe 'Markdown rendering' do
before do
allow(view).to receive(:get_markdown_without_frontmatter).and_return('[GitLab](https://about.gitlab.com/)')
assign(:clean_path, 'user/ssh')
end
it 'renders Markdown' do
render
expect(rendered).to have_link('GitLab', href: 'https://about.gitlab.com/')
end
end
end