Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2022-03-02 03:13:05 +00:00
parent 90c386a7b0
commit 1a54a22498
38 changed files with 392 additions and 191 deletions

View File

@ -1 +1 @@
416988ddd41d192114142a828eb039fac450d084 4e5774f37ab8581cf0a988ffca97a6252078ddc8

View File

@ -84,7 +84,7 @@ export default {
> >
<strong class="gl-mr-3"> {{ $options.i18n.barLabel }} </strong> <strong class="gl-mr-3"> {{ $options.i18n.barLabel }} </strong>
<gl-dropdown <gl-dropdown
class="gl-mr-6 qa-file-templates-bar" class="gl-mr-6"
:text="selectedTemplateType.name || $options.i18n.templateTypesDropdownLabel" :text="selectedTemplateType.name || $options.i18n.templateTypesDropdownLabel"
> >
<gl-dropdown-item <gl-dropdown-item
@ -102,7 +102,7 @@ export default {
@show="fetchTemplateTypes" @show="fetchTemplateTypes"
> >
<template #header> <template #header>
<gl-search-box-by-type v-model.trim="search" /> <gl-search-box-by-type v-model.trim="search" data-qa-selector="dropdown_filter_input" />
</template> </template>
<div> <div>
<gl-loading-icon v-if="isLoading" /> <gl-loading-icon v-if="isLoading" />

View File

@ -84,7 +84,7 @@ export default {
v-model="search" v-model="search"
:placeholder="__('Filter...')" :placeholder="__('Filter...')"
type="search" type="search"
class="dropdown-input-field qa-dropdown-filter-input" class="dropdown-input-field"
/> />
<gl-icon name="search" class="dropdown-input-search" /> <gl-icon name="search" class="dropdown-input-search" />
</div> </div>

View File

@ -3,6 +3,7 @@
module Projects module Projects
module Serverless module Serverless
class FunctionsController < Projects::ApplicationController class FunctionsController < Projects::ApplicationController
before_action :ensure_feature_enabled!
before_action :authorize_read_cluster! before_action :authorize_read_cluster!
feature_category :not_owned feature_category :not_owned
@ -69,6 +70,10 @@ module Projects
def serialize_function(function) def serialize_function(function)
Projects::Serverless::ServiceSerializer.new(current_user: @current_user, project: project).represent(function) Projects::Serverless::ServiceSerializer.new(current_user: @current_user, project: project).represent(function)
end end
def ensure_feature_enabled!
render_404 unless Feature.enabled?(:deprecated_serverless, project, default_enabled: :yaml, type: :ops)
end
end end
end end
end end

View File

@ -1,18 +0,0 @@
# frozen_string_literal: true
# Overrides `as_json` and `to_json` to raise an exception when called in order
# to prevent accidentally exposing attributes
#
# Not that would ever happen... but just in case.
module BlocksJsonSerialization
extend ActiveSupport::Concern
JsonSerializationError = Class.new(StandardError)
def to_json(*)
raise JsonSerializationError,
"JSON serialization has been disabled on #{self.class.name}"
end
alias_method :as_json, :to_json
end

View File

@ -0,0 +1,32 @@
# frozen_string_literal: true
# Overrides `#serializable_hash` to raise an exception when called without the `only` option
# in order to prevent accidentally exposing attributes.
#
# An `unsafe: true` option can also be passed in to bypass this check.
#
# `#serializable_hash` is used by ActiveModel serializers like `ActiveModel::Serializers::JSON`
# which overrides `#as_json` and `#to_json`.
#
module BlocksUnsafeSerialization
extend ActiveSupport::Concern
extend ::Gitlab::Utils::Override
UnsafeSerializationError = Class.new(StandardError)
override :serializable_hash
def serializable_hash(options = nil)
return super if allow_serialization?(options)
raise UnsafeSerializationError,
"Serialization has been disabled on #{self.class.name}"
end
private
def allow_serialization?(options = nil)
return false unless options
!!(options[:only] || options[:unsafe])
end
end

View File

@ -38,6 +38,7 @@ class Project < ApplicationRecord
include GitlabRoutingHelper include GitlabRoutingHelper
include BulkMemberAccessLoad include BulkMemberAccessLoad
include RunnerTokenExpirationInterval include RunnerTokenExpirationInterval
include BlocksUnsafeSerialization
extend Gitlab::Cache::RequestCache extend Gitlab::Cache::RequestCache
extend Gitlab::Utils::Override extend Gitlab::Utils::Override
@ -3047,6 +3048,10 @@ class Project < ApplicationRecord
Projects::SyncEvent.enqueue_worker Projects::SyncEvent.enqueue_worker
end end
end end
def allow_serialization?(options = nil)
Feature.disabled?(:block_project_serialization, self, default_enabled: :yaml) || super
end
end end
Project.prepend_mod_with('Project') Project.prepend_mod_with('Project')

View File

@ -14,7 +14,12 @@ class ProjectImportData < ApplicationRecord
insecure_mode: true, insecure_mode: true,
algorithm: 'aes-256-cbc' algorithm: 'aes-256-cbc'
serialize :data, JSON # rubocop:disable Cop/ActiveRecordSerialize # NOTE
# We are serializing a project as `data` in an "unsafe" way here
# because the credentials are necessary for a successful import.
# This is safe because the serialization is only going between rails
# and the database, never to any end users.
serialize :data, Serializers::UnsafeJson # rubocop:disable Cop/ActiveRecordSerialize
validates :project, presence: true validates :project, presence: true

View File

@ -16,7 +16,7 @@ class User < ApplicationRecord
include FeatureGate include FeatureGate
include CreatedAtFilterable include CreatedAtFilterable
include BulkMemberAccessLoad include BulkMemberAccessLoad
include BlocksJsonSerialization include BlocksUnsafeSerialization
include WithUploads include WithUploads
include OptionallySearch include OptionallySearch
include FromUnion include FromUnion

View File

@ -25,9 +25,9 @@
%td %td
- if user - if user
= link_to _('Remove user & report'), admin_abuse_report_path(abuse_report, remove_user: true), = link_to _('Remove user & report'), admin_abuse_report_path(abuse_report, remove_user: true),
data: { confirm: _("USER %{user} WILL BE REMOVED! Are you sure?") % { user: user.name } }, remote: true, method: :delete, class: "gl-button btn btn-block btn-danger js-remove-tr" data: { confirm: _("USER %{user} WILL BE REMOVED! Are you sure?") % { user: user.name }, confirm_btn_variant: "danger" }, aria: { label: _('Remove user & report') }, remote: true, method: :delete, class: "gl-button btn btn-block btn-danger js-remove-tr"
- if user && !user.blocked? - if user && !user.blocked?
= link_to _('Block user'), block_admin_user_path(user), data: {confirm: _('USER WILL BE BLOCKED! Are you sure?')}, method: :put, class: "gl-button btn btn-default btn-block" = link_to _('Block user'), block_admin_user_path(user), data: { confirm: _('USER WILL BE BLOCKED! Are you sure?') }, aria: { label: _('Block user') }, method: :put, class: "gl-button btn btn-default btn-block"
- else - else
.gl-button.btn.btn-default.disabled.btn-block .gl-button.btn.btn-default.disabled.btn-block
= _('Already blocked') = _('Already blocked')

View File

@ -8,17 +8,17 @@
= f.label :password_authentication_enabled_for_web, class: 'form-check-label' do = f.label :password_authentication_enabled_for_web, class: 'form-check-label' do
= _('Allow password authentication for the web interface') = _('Allow password authentication for the web interface')
.form-text.text-muted .form-text.text-muted
= _('When inactive, an external authentication provider must be used.') = _('Clear this checkbox to use an external authentication provider instead.')
.form-group .form-group
.form-check .form-check
= f.check_box :password_authentication_enabled_for_git, class: 'form-check-input' = f.check_box :password_authentication_enabled_for_git, class: 'form-check-input'
= f.label :password_authentication_enabled_for_git, class: 'form-check-label' do = f.label :password_authentication_enabled_for_git, class: 'form-check-label' do
= _('Allow password authentication for Git over HTTP(S)') = _('Allow password authentication for Git over HTTP(S)')
.form-text.text-muted .form-text.text-muted
When inactive, a Personal Access Token
- if Gitlab::Auth::Ldap::Config.enabled? - if Gitlab::Auth::Ldap::Config.enabled?
or LDAP password = _('Clear this checkbox to use a personal access token or LDAP password instead.')
must be used to authenticate. - else
= _('Clear this checkbox to use a personal access token instead.')
- if omniauth_enabled? && button_based_providers.any? - if omniauth_enabled? && button_based_providers.any?
%fieldset.form-group %fieldset.form-group
%legend.gl-font-base.gl-mb-3.gl-border-none.gl-font-weight-bold= _('Enabled OAuth authentication sources') %legend.gl-font-base.gl-mb-3.gl-border-none.gl-font-weight-bold= _('Enabled OAuth authentication sources')

View File

@ -0,0 +1,8 @@
---
name: block_project_serialization
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/81900
rollout_issue_url:
milestone: '14.9'
type: development
group: group::workspace
default_enabled: false

View File

@ -0,0 +1,8 @@
---
name: deprecated_serverless
introduced_by_url: 'https://gitlab.com/gitlab-org/gitlab/-/merge_requests/81493'
rollout_issue_url: 'https://gitlab.com/gitlab-org/gitlab/-/issues/353901'
milestone: '14.9'
type: ops
group: 'group::configure'
default_enabled: true

View File

@ -4,45 +4,19 @@ group: Distribution
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
--- ---
# Puma **(FREE SELF)** # Configure the bundled Puma instance of the GitLab package **(FREE SELF)**
Puma is a simple, fast, multi-threaded, and highly concurrent HTTP 1.1 server for Puma is a fast, multi-threaded, and highly concurrent HTTP 1.1 server for
Ruby applications. It's the default GitLab web server since GitLab 13.0 Ruby applications. It runs the core Rails application that provides the user-facing
and has replaced Unicorn. From GitLab 14.0, Unicorn is no longer supported. features of GitLab.
NOTE: ## Reducing memory use
Starting with GitLab 13.0, Puma is the default web server and Unicorn has been disabled.
In GitLab 14.0, Unicorn was removed from the Linux package and only Puma is available.
## Configure Puma To reduce memory use, Puma forks worker processes. Each time a worker is created,
it shares memory with the primary process. The worker uses additional memory only
when it changes or adds to its memory pages.
To configure Puma: Memory use increases over time, but you can use Puma Worker Killer to recover memory.
1. Determine suitable Puma worker and thread [settings](../../install/requirements.md#puma-settings).
1. If you're switching from Unicorn, [convert any custom settings to Puma](#convert-unicorn-settings-to-puma).
1. For multi-node deployments, configure the load balancer to use the
[readiness check](../load_balancer.md#readiness-check).
1. Reconfigure GitLab so the above changes take effect:
```shell
sudo gitlab-ctl reconfigure
```
For Helm-based deployments, see the
[`webservice` chart documentation](https://docs.gitlab.com/charts/charts/gitlab/webservice/index.html).
For more details about the Puma configuration, see the
[Puma documentation](https://github.com/puma/puma#configuration).
## Puma Worker Killer
Puma forks worker processes as part of a strategy to reduce memory use.
Each time a worker is created, it shares memory with the primary process and
only uses additional memory when it makes changes or additions to its memory pages.
Memory use by workers therefore increases over time, and Puma Worker Killer is the
mechanism that recovers this memory.
By default: By default:
@ -50,6 +24,8 @@ By default:
exceeds a [memory limit](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/cluster/puma_worker_killer_initializer.rb). exceeds a [memory limit](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/cluster/puma_worker_killer_initializer.rb).
- Rolling restarts of Puma workers are performed every 12 hours. - Rolling restarts of Puma workers are performed every 12 hours.
### Change the memory limit setting
To change the memory limit setting: To change the memory limit setting:
1. Edit `/etc/gitlab/gitlab.rb`: 1. Edit `/etc/gitlab/gitlab.rb`:
@ -58,26 +34,28 @@ To change the memory limit setting:
puma['per_worker_max_memory_mb'] = 1024 puma['per_worker_max_memory_mb'] = 1024
``` ```
1. Reconfigure GitLab for the changes to take effect: 1. Reconfigure GitLab:
```shell ```shell
sudo gitlab-ctl reconfigure sudo gitlab-ctl reconfigure
``` ```
There are costs associated with killing and replacing workers including When workers are killed and replaced, capacity to run GitLab is reduced,
reduced capacity to run GitLab, and CPU that is consumed and CPU is consumed. Set `per_worker_max_memory_mb` to a higher value if the worker killer
restarting the workers. `per_worker_max_memory_mb` should be set to a is replacing workers too often.
higher value if the worker killer is replacing workers too often.
Worker count is calculated based on CPU cores, so a small GitLab deployment Worker count is calculated based on CPU cores. A small GitLab deployment
with 4-8 workers may experience performance issues if workers are being restarted with 4-8 workers may experience performance issues if workers are being restarted
frequently, once or more per minute. This is too often. too often (once or more per minute).
A higher value of `1200` or more would be beneficial if the server has free memory. A higher value of `1200` or more would be beneficial if the server has free memory.
The worker killer checks every 20 seconds, and can be monitored using ### Monitor worker memory
[the Puma log](../logs.md#puma_stdoutlog) `/var/log/gitlab/puma/puma_stdout.log`.
For example, for GitLab 13.5: The worker killer checks memory every 20 seconds.
To monitor the worker killer, use [the Puma log](../logs.md#puma_stdoutlog) `/var/log/gitlab/puma/puma_stdout.log`.
For example:
```plaintext ```plaintext
PumaWorkerKiller: Out of memory. 4 workers consuming total: 4871.23828125 MB PumaWorkerKiller: Out of memory. 4 workers consuming total: 4871.23828125 MB
@ -88,9 +66,9 @@ From this output:
- The formula that calculates the maximum memory value results in workers - The formula that calculates the maximum memory value results in workers
being killed before they reach the `per_worker_max_memory_mb` value. being killed before they reach the `per_worker_max_memory_mb` value.
- The default values for the formula before GitLab 13.5 were 550MB for the primary - In GitLab 13.4 and earlier, the default values for the formula were 550MB for the primary
and `per_worker_max_memory_mb` specified 850MB for each worker. and 850MB for each worker.
- As of GitLab 13.5 the values are primary: 800MB, worker: 1024MB. - In GitLab 13.5 and later, the values are primary: 800MB, worker: 1024MB.
- The threshold for workers to be killed is set at 98% of the limit: - The threshold for workers to be killed is set at 98% of the limit:
```plaintext ```plaintext
@ -102,16 +80,15 @@ From this output:
Increasing the maximum to `1200`, for example, would set a `max: 5488 MB` value. Increasing the maximum to `1200`, for example, would set a `max: 5488 MB` value.
Workers use additional memory on top of the shared memory, how much Workers use additional memory on top of the shared memory. The amount of memory
depends on a site's use of GitLab. depends on a site's use of GitLab.
## Worker timeout ## Change the worker timeout
A [timeout of 60 seconds](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/initializers/rack_timeout.rb) The default Puma [timeout is 60 seconds](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/initializers/rack_timeout.rb).
is used when Puma is enabled.
NOTE: NOTE:
Unlike Unicorn, the `puma['worker_timeout']` setting does not set the maximum request duration. The `puma['worker_timeout']` setting does not set the maximum request duration.
To change the worker timeout to 600 seconds: To change the worker timeout to 600 seconds:
@ -123,26 +100,38 @@ To change the worker timeout to 600 seconds:
} }
``` ```
1. Reconfigure GitLab for the changes to take effect: 1. Reconfigure GitLab:
```shell ```shell
sudo gitlab-ctl reconfigure sudo gitlab-ctl reconfigure
``` ```
## Memory-constrained environments ## Disable Puma clustered mode in memory-constrained environments
In a memory-constrained environment with less than 4GB of RAM available, consider disabling Puma In a memory-constrained environment with less than 4GB of RAM available, consider disabling Puma
[Clustered mode](https://github.com/puma/puma#clustered-mode). [clustered mode](https://github.com/puma/puma#clustered-mode).
Configuring Puma by setting the amount of `workers` to `0` could reduce memory usage by hundreds of MB. Set the number of `workers` to `0` to reduce memory usage by hundreds of MB:
1. Edit `/etc/gitlab/gitlab.rb`:
```ruby
puma['worker_processes'] = 0
```
1. Reconfigure GitLab:
```shell
sudo gitlab-ctl reconfigure
```
Unlike in a clustered mode, which is set up by default, only a single Puma process would serve the application.
For details on Puma worker and thread settings, see the [Puma requirements](../../install/requirements.md#puma-settings). For details on Puma worker and thread settings, see the [Puma requirements](../../install/requirements.md#puma-settings).
Unlike in a Clustered mode, which is set up by default, only a single Puma process would serve the application. The downside of running Puma in this configuration is the reduced throughput, which can be
considered a fair tradeoff in a memory-constrained environment.
The downside of running Puma with such configuration is the reduced throughput, which could be When running Puma in single mode, some features are not supported:
considered as a fair tradeoff in a memory-constraint environment.
When running Puma in Single mode, some features are not supported:
- [Phased restart](https://gitlab.com/gitlab-org/gitlab/-/issues/300665) - [Phased restart](https://gitlab.com/gitlab-org/gitlab/-/issues/300665)
- [Puma Worker Killer](https://gitlab.com/gitlab-org/gitlab/-/issues/300664) - [Puma Worker Killer](https://gitlab.com/gitlab-org/gitlab/-/issues/300664)
@ -151,22 +140,23 @@ To learn more, visit [epic 5303](https://gitlab.com/groups/gitlab-org/-/epics/53
## Performance caveat when using Puma with Rugged ## Performance caveat when using Puma with Rugged
For deployments where NFS is used to store Git repository, we allow GitLab to use For deployments where NFS is used to store Git repositories, GitLab uses
[direct Git access](../gitaly/index.md#direct-access-to-git-in-gitlab) to improve performance using [direct Git access](../gitaly/index.md#direct-access-to-git-in-gitlab) to improve performance by using
[Rugged](https://github.com/libgit2/rugged). [Rugged](https://github.com/libgit2/rugged).
Rugged usage is automatically enabled if direct Git access Rugged usage is automatically enabled if direct Git access
[is available](../gitaly/index.md#how-it-works) [is available](../gitaly/index.md#how-it-works)
and Puma is running single threaded, unless it is disabled by and Puma is running single threaded, unless it is disabled by a
[feature flags](../../development/gitaly.md#legacy-rugged-code). [feature flag](../../development/gitaly.md#legacy-rugged-code).
MRI Ruby uses a GVL. This allows MRI Ruby to be multi-threaded, but running at MRI Ruby uses a Global VM Lock (GVL). GVL allows MRI Ruby to be multi-threaded, but running at
most on a single core. Since Rugged can use a thread for long periods of most on a single core.
time (due to intensive I/O operations of Git access), this can starve other threads
that might be processing requests. This is not a case for Unicorn or Puma running
in a single thread mode, as concurrently at most one request is being processed.
We are actively working on removing Rugged usage. Even though performance without Rugged Git includes intensive I/O operations. When Rugged uses a thread for a long period of time,
other threads that might be processing requests can starve. Puma running in single thread mode
does not have this issue, because concurrently at most one request is being processed.
GitLab is working to remove Rugged usage. Even though performance without Rugged
is acceptable today, in some cases it might be still beneficial to run with it. is acceptable today, in some cases it might be still beneficial to run with it.
Given the caveat of running Rugged with multi-threaded Puma, and acceptable Given the caveat of running Rugged with multi-threaded Puma, and acceptable
@ -177,55 +167,70 @@ This default behavior may not be the optimal configuration in some situations. I
plays an important role in your deployment, we suggest you benchmark to find the plays an important role in your deployment, we suggest you benchmark to find the
optimal configuration: optimal configuration:
- The safest option is to start with single-threaded Puma. When working with - The safest option is to start with single-threaded Puma.
Rugged, single-threaded Puma works the same as Unicorn. - To force Rugged to be used with multi-threaded Puma, you can use a
- To force Rugged to be used with multi-threaded Puma, you can use [feature flag](../../development/gitaly.md#legacy-rugged-code).
[feature flags](../../development/gitaly.md#legacy-rugged-code).
## Convert Unicorn settings to Puma ## Switch from Unicorn to Puma
NOTE: NOTE:
Starting with GitLab 13.0, Puma is the default web server and Unicorn has been For Helm-based deployments, see the
disabled by default. In GitLab 14.0, Unicorn was removed from the Linux package [`webservice` chart documentation](https://docs.gitlab.com/charts/charts/gitlab/webservice/index.html).
and only Puma is available.
Puma has a multi-thread architecture which uses less memory than a multi-process Starting with GitLab 13.0, Puma is the default web server and Unicorn has been disabled.
In GitLab 14.0, [Unicorn was removed](../../update/removals.md#unicorn-in-gitlab-self-managed)
from the Linux package and is no longer supported.
Puma has a multi-thread architecture that uses less memory than a multi-process
application server like Unicorn. On GitLab.com, we saw a 40% reduction in memory application server like Unicorn. On GitLab.com, we saw a 40% reduction in memory
consumption. Most Rails applications requests normally include a proportion of I/O wait time. consumption. Most Rails application requests normally include a proportion of I/O wait time.
During I/O wait time MRI Ruby releases the GVL (Global VM Lock) to other threads. During I/O wait time, MRI Ruby releases the GVL to other threads.
Multi-threaded Puma can therefore still serve more requests than a single process. Multi-threaded Puma can therefore still serve more requests than a single process.
When switching to Puma, any Unicorn server configuration will _not_ carry over When switching to Puma, any Unicorn server configuration will _not_ carry over
automatically, due to differences between the two application servers. automatically, due to differences between the two application servers.
The table below summarizes which Unicorn configuration keys correspond to those To switch from Unicorn to Puma:
in Puma when using the Linux package, and which ones have no corresponding counterpart.
| Unicorn | Puma | 1. Determine suitable Puma [worker and thread settings](../../install/requirements.md#puma-settings).
| ------------------------------------ | ---------------------------------- | 1. Convert any custom Unicorn settings to Puma.
| `unicorn['enable']` | `puma['enable']` |
| `unicorn['worker_timeout']` | `puma['worker_timeout']` |
| `unicorn['worker_processes']` | `puma['worker_processes']` |
| n/a | `puma['ha']` |
| n/a | `puma['min_threads']` |
| n/a | `puma['max_threads']` |
| `unicorn['listen']` | `puma['listen']` |
| `unicorn['port']` | `puma['port']` |
| `unicorn['socket']` | `puma['socket']` |
| `unicorn['pidfile']` | `puma['pidfile']` |
| `unicorn['tcp_nopush']` | n/a |
| `unicorn['backlog_socket']` | n/a |
| `unicorn['somaxconn']` | `puma['somaxconn']` |
| n/a | `puma['state_path']` |
| `unicorn['log_directory']` | `puma['log_directory']` |
| `unicorn['worker_memory_limit_min']` | n/a |
| `unicorn['worker_memory_limit_max']` | `puma['per_worker_max_memory_mb']` |
| `unicorn['exporter_enabled']` | `puma['exporter_enabled']` |
| `unicorn['exporter_address']` | `puma['exporter_address']` |
| `unicorn['exporter_port']` | `puma['exporter_port']` |
## Puma exporter The table below summarizes which Unicorn configuration keys correspond to those
in Puma when using the Linux package, and which ones have no corresponding counterpart.
You can use the Puma exporter to measure various Puma metrics. For more information, see | Unicorn | Puma |
[Puma exporter](../monitoring/prometheus/puma_exporter.md). | ------------------------------------ | ---------------------------------- |
| `unicorn['enable']` | `puma['enable']` |
| `unicorn['worker_timeout']` | `puma['worker_timeout']` |
| `unicorn['worker_processes']` | `puma['worker_processes']` |
| n/a | `puma['ha']` |
| n/a | `puma['min_threads']` |
| n/a | `puma['max_threads']` |
| `unicorn['listen']` | `puma['listen']` |
| `unicorn['port']` | `puma['port']` |
| `unicorn['socket']` | `puma['socket']` |
| `unicorn['pidfile']` | `puma['pidfile']` |
| `unicorn['tcp_nopush']` | n/a |
| `unicorn['backlog_socket']` | n/a |
| `unicorn['somaxconn']` | `puma['somaxconn']` |
| n/a | `puma['state_path']` |
| `unicorn['log_directory']` | `puma['log_directory']` |
| `unicorn['worker_memory_limit_min']` | n/a |
| `unicorn['worker_memory_limit_max']` | `puma['per_worker_max_memory_mb']` |
| `unicorn['exporter_enabled']` | `puma['exporter_enabled']` |
| `unicorn['exporter_address']` | `puma['exporter_address']` |
| `unicorn['exporter_port']` | `puma['exporter_port']` |
1. Reconfigure GitLab:
```shell
sudo gitlab-ctl reconfigure
```
1. Optional. For multi-node deployments, configure the load balancer to use the
[readiness check](../load_balancer.md#readiness-check).
## Related topics
- [Use the Puma exporter to measure various Puma metrics](../monitoring/prometheus/puma_exporter.md)

View File

@ -225,7 +225,7 @@ gitlab_rails['env'] = {
``` ```
For source installations, set the environment variable. For source installations, set the environment variable.
Refer to [Puma Worker timeout](../operations/puma.md#worker-timeout). Refer to [Puma Worker timeout](../operations/puma.md#change-the-worker-timeout).
[Reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) GitLab for the changes to take effect. [Reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) GitLab for the changes to take effect.

View File

@ -9,6 +9,23 @@ info: To determine the technical writer assigned to the Stage/Group associated w
There are multiple types of permissions across GitLab, and when implementing There are multiple types of permissions across GitLab, and when implementing
anything that deals with permissions, all of them should be considered. anything that deals with permissions, all of them should be considered.
## Instance
### User types
Each user can be one of the following types:
- Regular.
- External - access to groups and projects only if direct member.
- [Internal users](internal_users.md) - system created.
- [Auditor](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/policies/ee/base_policy.rb#L9):
- No access to projects or groups settings menu.
- No access to Admin Area.
- Read-only access to everything else.
- [Administrator](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/policies/base_policy.rb#L6) - read-write access.
See the [permissions page](../user/permissions.md) for details on how each user type is used.
## Groups and Projects ## Groups and Projects
### General permissions ### General permissions

View File

@ -258,7 +258,7 @@ works.
### Puma per worker maximum memory ### Puma per worker maximum memory
By default, each Puma worker will be limited to 1024 MB of memory. By default, each Puma worker will be limited to 1024 MB of memory.
This setting [can be adjusted](../administration/operations/puma.md#puma-worker-killer) and should be considered This setting [can be adjusted](../administration/operations/puma.md#change-the-memory-limit-setting) and should be considered
if you need to increase the number of Puma workers. if you need to increase the number of Puma workers.
## Redis and Sidekiq ## Redis and Sidekiq

View File

@ -22,6 +22,6 @@ The following timeouts are available.
| Timeout | Default | Description | | Timeout | Default | Description |
|:--------|:-----------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| |:--------|:-----------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Default | 55 seconds | Timeout for most Gitaly calls (not enforced for `git` `fetch` and `push` operations, or Sidekiq jobs). For example, checking if a repository exists on disk. Makes sure that Gitaly calls made within a web request cannot exceed the entire request timeout. It should be shorter than the [worker timeout](../../../administration/operations/puma.md#worker-timeout) that can be configured for [Puma](../../../install/requirements.md#puma-settings). If a Gitaly call timeout exceeds the worker timeout, the remaining time from the worker timeout is used to avoid having to terminate the worker. | | Default | 55 seconds | Timeout for most Gitaly calls (not enforced for `git` `fetch` and `push` operations, or Sidekiq jobs). For example, checking if a repository exists on disk. Makes sure that Gitaly calls made within a web request cannot exceed the entire request timeout. It should be shorter than the [worker timeout](../../../administration/operations/puma.md#change-the-worker-timeout) that can be configured for [Puma](../../../install/requirements.md#puma-settings). If a Gitaly call timeout exceeds the worker timeout, the remaining time from the worker timeout is used to avoid having to terminate the worker. |
| Fast | 10 seconds | Timeout for fast Gitaly operations used within requests, sometimes multiple times. For example, checking if a repository exists on disk. If fast operations exceed this threshold, there may be a problem with a storage shard. Failing fast can help maintain the stability of the GitLab instance. | | Fast | 10 seconds | Timeout for fast Gitaly operations used within requests, sometimes multiple times. For example, checking if a repository exists on disk. If fast operations exceed this threshold, there may be a problem with a storage shard. Failing fast can help maintain the stability of the GitLab instance. |
| Medium | 30 seconds | Timeout for Gitaly operations that should be fast (possibly within requests) but preferably not used multiple times within a request. For example, loading blobs. Timeout that should be set between Default and Fast. | | Medium | 30 seconds | Timeout for Gitaly operations that should be fast (possibly within requests) but preferably not used multiple times within a request. For example, loading blobs. Timeout that should be set between Default and Fast. |

View File

@ -299,7 +299,7 @@ for `shared_buffers` is quite high, and we are
## Puma ## Puma
GitLab.com uses the default of 60 seconds for [Puma request timeouts](../../administration/operations/puma.md#worker-timeout). GitLab.com uses the default of 60 seconds for [Puma request timeouts](../../administration/operations/puma.md#change-the-worker-timeout).
## GitLab.com-specific rate limits ## GitLab.com-specific rate limits

View File

@ -806,9 +806,7 @@ The group's new subgroups have push rules set for them based on either:
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/285458) in GitLab 13.9. [Deployed behind the `group_merge_request_approval_settings_feature_flag` flag](../../administration/feature_flags.md), disabled by default. > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/285458) in GitLab 13.9. [Deployed behind the `group_merge_request_approval_settings_feature_flag` flag](../../administration/feature_flags.md), disabled by default.
> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/285410) in GitLab 14.5. > - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/285410) in GitLab 14.5.
> - [Feature flag `group_merge_request_approval_settings_feature_flag`](https://gitlab.com/gitlab-org/gitlab/-/issues/343872) removed in GitLab 14.9.
FLAG:
On self-managed GitLab, by default this feature is available. To hide the feature per group, ask an administrator to [disable the feature flag](../../administration/feature_flags.md) named `group_merge_request_approval_settings_feature_flag`. On GitLab.com, this feature is available.
Group approval rules manage [project merge request approval rules](../project/merge_requests/approvals/index.md) Group approval rules manage [project merge request approval rules](../project/merge_requests/approvals/index.md)
at the top-level group level. These rules [cascade to all projects](../project/merge_requests/approvals/settings.md#settings-cascading) at the top-level group level. These rules [cascade to all projects](../project/merge_requests/approvals/settings.md#settings-cascading)

View File

@ -76,12 +76,15 @@ You can also [integrate](project/integrations/overview.md) GitLab with numerous
There are several types of users in GitLab: There are several types of users in GitLab:
- Regular users and GitLab.com users. <!-- Note: further description TBA --> - Regular users.
- [Groups](group/index.md) of users. - [Internal users](../development/internal_users.md) often referred to as bot or system users.
- GitLab [administrator area](admin_area/index.md) user. - [Auditor](permissions.md#auditor-users) with read access to self-managed instances.
- [GitLab Administrator](../administration/index.md) with full access to - [GitLab Administrator](../administration/index.md) with full access to
self-managed instances' features and settings. self-managed instances including settings and the [Admin Area](admin_area/index.md).
- [Internal users](../development/internal_users.md).
Each user can be a member in a [group](group/index.md).
See the [permissions page](permissions.md) for details on how each user type is used.
## User activity ## User activity

View File

@ -140,9 +140,7 @@ To learn more, see [Coverage check approval rule](../../../../ci/pipelines/setti
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/285410) in GitLab 14.4. [Deployed behind the `group_merge_request_approval_settings_feature_flag` flag](../../../../administration/feature_flags.md), disabled by default. > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/285410) in GitLab 14.4. [Deployed behind the `group_merge_request_approval_settings_feature_flag` flag](../../../../administration/feature_flags.md), disabled by default.
> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/285410) in GitLab 14.5. > - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/285410) in GitLab 14.5.
> - [Feature flag `group_merge_request_approval_settings_feature_flag`](https://gitlab.com/gitlab-org/gitlab/-/issues/343872) removed in GitLab 14.9.
FLAG:
On self-managed GitLab, by default this feature is available. To hide the feature per group, ask an administrator to [disable the feature flag](../../../../administration/feature_flags.md) named `group_merge_request_approval_settings_feature_flag`. On GitLab.com, this feature is available.
You can also enforce merge request approval settings: You can also enforce merge request approval settings:

View File

@ -0,0 +1,13 @@
# frozen_string_literal: true
module Serializers
class UnsafeJson
class << self
def dump(obj)
obj.to_json(unsafe: true)
end
delegate :load, to: :JSON
end
end
end

View File

@ -64,7 +64,7 @@ module Sidebars
end end
def serverless_menu_item def serverless_menu_item
unless can?(context.current_user, :read_cluster, context.project) unless Feature.enabled?(:deprecated_serverless, context.project, default_enabled: :yaml, type: :ops) && can?(context.current_user, :read_cluster, context.project)
return ::Sidebars::NilMenuItem.new(item_id: :serverless) return ::Sidebars::NilMenuItem.new(item_id: :serverless)
end end

View File

@ -7453,6 +7453,15 @@ msgstr ""
msgid "Clear templates search input" msgid "Clear templates search input"
msgstr "" msgstr ""
msgid "Clear this checkbox to use a personal access token instead."
msgstr ""
msgid "Clear this checkbox to use a personal access token or LDAP password instead."
msgstr ""
msgid "Clear this checkbox to use an external authentication provider instead."
msgstr ""
msgid "Clear weight" msgid "Clear weight"
msgstr "" msgstr ""
@ -41344,9 +41353,6 @@ msgstr ""
msgid "When enabled, job logs are collected by Datadog and displayed along with pipeline execution traces." msgid "When enabled, job logs are collected by Datadog and displayed along with pipeline execution traces."
msgstr "" msgstr ""
msgid "When inactive, an external authentication provider must be used."
msgstr ""
msgid "When merge requests and commits in the default branch close, any issues they reference also close." msgid "When merge requests and commits in the default branch close, any issues they reference also close."
msgstr "" msgstr ""

View File

@ -32,7 +32,7 @@ module QA
element :file_template_dropdown element :file_template_dropdown
end end
view 'app/assets/javascripts/ide/components/file_templates/dropdown.vue' do view 'app/assets/javascripts/ide/components/file_templates/bar.vue' do
element :dropdown_filter_input element :dropdown_filter_input
end end

View File

@ -5,8 +5,8 @@
# - If `dry_run` is true the script will list the users to be deleted by username, but it won't delete them # - If `dry_run` is true the script will list the users to be deleted by username, but it won't delete them
# - Specify `exclude_users` as a comma-separated list of usernames to not delete. # - Specify `exclude_users` as a comma-separated list of usernames to not delete.
# #
# Required environment variables: GITLAB_QA_ACCESS_TOKEN and GITLAB_ADDRESS # Required environment variables: GITLAB_QA_ADMIN_ACCESS_TOKEN and GITLAB_ADDRESS
# - GITLAB_QA_ACCESS_TOKEN must have admin API access # - GITLAB_QA_ADMIN_ACCESS_TOKEN must have admin API access
module QA module QA
module Tools module Tools
@ -19,9 +19,9 @@ module QA
def initialize(delete_before: (Date.today - 1).to_s, dry_run: 'false', exclude_users: nil) def initialize(delete_before: (Date.today - 1).to_s, dry_run: 'false', exclude_users: nil)
raise ArgumentError, "Please provide GITLAB_ADDRESS" unless ENV['GITLAB_ADDRESS'] raise ArgumentError, "Please provide GITLAB_ADDRESS" unless ENV['GITLAB_ADDRESS']
raise ArgumentError, "Please provide GITLAB_QA_ACCESS_TOKEN" unless ENV['GITLAB_QA_ACCESS_TOKEN'] raise ArgumentError, "Please provide GITLAB_QA_ADMIN_ACCESS_TOKEN" unless ENV['GITLAB_QA_ADMIN_ACCESS_TOKEN']
@api_client = Runtime::API::Client.new(ENV['GITLAB_ADDRESS'], personal_access_token: ENV['GITLAB_QA_ACCESS_TOKEN']) @api_client = Runtime::API::Client.new(ENV['GITLAB_ADDRESS'], personal_access_token: ENV['GITLAB_QA_ADMIN_ACCESS_TOKEN'])
@dry_run = !FALSY_VALUES.include?(dry_run.to_s.downcase) @dry_run = !FALSY_VALUES.include?(dry_run.to_s.downcase)
@delete_before = Date.parse(delete_before) @delete_before = Date.parse(delete_before)
@page_no = '1' @page_no = '1'
@ -29,7 +29,7 @@ module QA
end end
def run def run
puts "Deleting users with a username starting with 'qa-user-' created before #{@delete_before}..." puts "Deleting users with a username starting with 'qa-user-' or 'test-user-' created before #{@delete_before}..."
while page_no.present? while page_no.present?
users = fetch_test_users users = fetch_test_users

View File

@ -208,7 +208,7 @@ RSpec.describe Boards::ListsController do
sign_in(user) sign_in(user)
params = { namespace_id: project.namespace.to_param, params = { namespace_id: project.namespace.to_param,
project_id: project, project_id: project.id,
board_id: board.to_param, board_id: board.to_param,
id: list.to_param, id: list.to_param,
list: { position: position }, list: { position: position },
@ -221,7 +221,7 @@ RSpec.describe Boards::ListsController do
sign_in(user) sign_in(user)
params = { namespace_id: project.namespace.to_param, params = { namespace_id: project.namespace.to_param,
project_id: project, project_id: project.id,
board_id: board.to_param, board_id: board.to_param,
id: list.to_param, id: list.to_param,
list: setting, list: setting,

View File

@ -39,9 +39,24 @@ RSpec.describe Projects::Serverless::FunctionsController do
project_id: project.to_param) project_id: project.to_param)
end end
shared_examples_for 'behind :deprecated_serverless feature flag' do
before do
stub_feature_flags(deprecated_serverless: false)
end
it 'returns 404' do
action
expect(response).to have_gitlab_http_status(:not_found)
end
end
describe 'GET #index' do describe 'GET #index' do
let(:expected_json) { { 'knative_installed' => knative_state, 'functions' => functions } } let(:expected_json) { { 'knative_installed' => knative_state, 'functions' => functions } }
it_behaves_like 'behind :deprecated_serverless feature flag' do
let(:action) { get :index, params: params({ format: :json }) }
end
context 'when cache is being read' do context 'when cache is being read' do
let(:knative_state) { 'checking' } let(:knative_state) { 'checking' }
let(:functions) { [] } let(:functions) { [] }
@ -147,6 +162,10 @@ RSpec.describe Projects::Serverless::FunctionsController do
end end
describe 'GET #show' do describe 'GET #show' do
it_behaves_like 'behind :deprecated_serverless feature flag' do
let(:action) { get :show, params: params({ format: :json, environment_id: "*", id: "foo" }) }
end
context 'with function that does not exist' do context 'with function that does not exist' do
it 'returns 404' do it 'returns 404' do
get :show, params: params({ format: :json, environment_id: "*", id: "foo" }) get :show, params: params({ format: :json, environment_id: "*", id: "foo" })
@ -239,6 +258,10 @@ RSpec.describe Projects::Serverless::FunctionsController do
end end
describe 'GET #metrics' do describe 'GET #metrics' do
it_behaves_like 'behind :deprecated_serverless feature flag' do
let(:action) { get :metrics, params: params({ format: :json, environment_id: "*", id: "foo" }) }
end
context 'invalid data' do context 'invalid data' do
it 'has a bad function name' do it 'has a bad function name' do
get :metrics, params: params({ format: :json, environment_id: "*", id: "foo" }) get :metrics, params: params({ format: :json, environment_id: "*", id: "foo" })

View File

@ -33,7 +33,7 @@ RSpec.describe Banzai::Filter::IssuableReferenceExpansionFilter do
end end
it 'ignores non-issuable links' do it 'ignores non-issuable links' do
link = create_link('text', project: project, reference_type: 'issue') link = create_link('text', project: project.id, reference_type: 'issue')
doc = filter(link, context) doc = filter(link, context)
expect(doc.css('a').last.text).to eq('text') expect(doc.css('a').last.text).to eq('text')

View File

@ -0,0 +1,27 @@
# frozen_string_literal: true
require 'fast_spec_helper'
require 'oj'
RSpec.describe Serializers::UnsafeJson do
let(:result) { double(:result) }
describe '.dump' do
let(:obj) { { key: "value" } }
it 'calls object#to_json with unsafe: true and returns the result' do
expect(obj).to receive(:to_json).with(unsafe: true).and_return(result)
expect(described_class.dump(obj)).to eq(result)
end
end
describe '.load' do
let(:data_string) { '{"key":"value","variables":[{"key":"VAR1","value":"VALUE1"}]}' }
let(:data_hash) { Gitlab::Json.parse(data_string) }
it 'calls JSON.load and returns the result' do
expect(JSON).to receive(:load).with(data_hash).and_return(result)
expect(described_class.load(data_hash)).to eq(result)
end
end
end

View File

@ -92,6 +92,14 @@ RSpec.describe Sidebars::Projects::Menus::InfrastructureMenu do
let(:item_id) { :serverless } let(:item_id) { :serverless }
it_behaves_like 'access rights checks' it_behaves_like 'access rights checks'
context 'when feature :deprecated_serverless is disabled' do
before do
stub_feature_flags(deprecated_serverless: false)
end
it { is_expected.to be_nil }
end
end end
describe 'Terraform' do describe 'Terraform' do

View File

@ -1,22 +0,0 @@
# frozen_string_literal: true
require 'spec_helper'
RSpec.describe BlocksJsonSerialization do
before do
stub_const('DummyModel', Class.new)
DummyModel.class_eval do
include BlocksJsonSerialization
end
end
it 'blocks as_json' do
expect { DummyModel.new.as_json }
.to raise_error(described_class::JsonSerializationError, /DummyModel/)
end
it 'blocks to_json' do
expect { DummyModel.new.to_json }
.to raise_error(described_class::JsonSerializationError, /DummyModel/)
end
end

View File

@ -0,0 +1,17 @@
# frozen_string_literal: true
require 'spec_helper'
RSpec.describe BlocksUnsafeSerialization do
before do
stub_const('DummyModel', Class.new)
DummyModel.class_eval do
include ActiveModel::Serializers::JSON
include BlocksUnsafeSerialization
end
end
it_behaves_like 'blocks unsafe serialization' do
let(:object) { DummyModel.new }
end
end

View File

@ -8022,6 +8022,20 @@ RSpec.describe Project, factory_default: :keep do
end end
end end
describe 'serialization' do
let(:object) { build(:project) }
it_behaves_like 'blocks unsafe serialization'
context 'when feature flag block_project_serialization is disabled' do
before do
stub_feature_flags(block_project_serialization: false)
end
it_behaves_like 'allows unsafe serialization'
end
end
describe '#runners_token' do describe '#runners_token' do
let_it_be(:project) { create(:project) } let_it_be(:project) { create(:project) }

View File

@ -17,7 +17,7 @@ RSpec.describe User do
it { is_expected.to include_module(Referable) } it { is_expected.to include_module(Referable) }
it { is_expected.to include_module(Sortable) } it { is_expected.to include_module(Sortable) }
it { is_expected.to include_module(TokenAuthenticatable) } it { is_expected.to include_module(TokenAuthenticatable) }
it { is_expected.to include_module(BlocksJsonSerialization) } it { is_expected.to include_module(BlocksUnsafeSerialization) }
it { is_expected.to include_module(AsyncDeviseEmail) } it { is_expected.to include_module(AsyncDeviseEmail) }
end end

View File

@ -0,0 +1,26 @@
# frozen_string_literal: true
require 'spec_helper'
# Requires a context with:
# - object
#
RSpec.shared_examples 'blocks unsafe serialization' do
it 'blocks as_json' do
expect { object.as_json }.to raise_error(described_class::UnsafeSerializationError, /#{object.class.name}/)
end
it 'blocks to_json' do
expect { object.to_json }.to raise_error(described_class::UnsafeSerializationError, /#{object.class.name}/)
end
end
RSpec.shared_examples 'allows unsafe serialization' do
it 'allows as_json' do
expect { object.as_json }.not_to raise_error
end
it 'allows to_json' do
expect { object.to_json }.not_to raise_error
end
end

View File

@ -68,6 +68,29 @@ RSpec.shared_examples 'note entity' do
end end
end end
describe ':outdated_line_change_path' do
before do
allow(note).to receive(:show_outdated_changes?).and_return(show_outdated_changes)
end
context 'when note shows outdated changes' do
let(:show_outdated_changes) { true }
it 'returns correct outdated_line_change_namespace_project_note_path' do
path = "/#{note.project.namespace.path}/#{note.project.path}/notes/#{note.id}/outdated_line_change"
expect(subject[:outdated_line_change_path]).to eq(path)
end
end
context 'when note does not show outdated changes' do
let(:show_outdated_changes) { false }
it 'does not expose outdated_line_change_path' do
expect(subject).not_to include(:outdated_line_change_path)
end
end
end
context 'when note was edited' do context 'when note was edited' do
before do before do
note.update!(updated_at: 1.minute.from_now, updated_by: user) note.update!(updated_at: 1.minute.from_now, updated_by: user)