root
/
gitlab-ce
mirror of https://gitlab.com/free-releases/gitlab-ce.git
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2023-07-07 18:08:41 +00:00
parent 048eea4614
commit 0551e6537b
51 changed files with 597 additions and 377 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

74
.gitlab/ci/package-and-test/main.gitlab-ci.yml
View File

@ -238,7 +238,9 @@ decomposition-multiple-db-selective-parallel:
# ========== object-storage ===========
object-storage:
extends: .qa
extends:
- .qa
- .failure-videos
parallel: 2
variables:
QA_SCENARIO: Test::Instance::Image
@ -274,7 +276,9 @@ object-storage-selective-parallel:
# ========== object-storage-aws ===========
object-storage-aws:
extends: object-storage
extends:
- object-storage
- .failure-videos
variables:
AWS_S3_ACCESS_KEY: $QA_AWS_S3_ACCESS_KEY
AWS_S3_BUCKET_NAME: $QA_AWS_S3_BUCKET_NAME
@ -304,7 +308,9 @@ object-storage-aws-selective-parallel:
# ========== object-storage-gcs ===========
object-storage-gcs:
extends: object-storage
extends:
- object-storage
- .failure-videos
variables:
GCS_BUCKET_NAME: $QA_GCS_BUCKET_NAME
GOOGLE_PROJECT: $QA_GOOGLE_PROJECT
@ -362,12 +368,11 @@ group-saml:
- !reference [.rules:test:manual, rules]
oauth:
extends: .qa
extends:
- .qa
- .failure-videos
variables:
QA_SCENARIO: Test::Integration::OAuth
USE_SELENOID: "true"
QA_RECORD_VIDEO: "true"
QA_REMOTE_GRID: "selenoid:4444"
rules:
- !reference [.rules:test:qa-default-branch, rules]
- if: $QA_SUITES =~ /Test::Integration::OAuth/
@ -383,7 +388,9 @@ instance-saml:
- !reference [.rules:test:manual, rules]
jira:
extends: .qa
extends:
- .qa
- .failure-videos
variables:
QA_SCENARIO: Test::Integration::Jira
rules:
@ -401,7 +408,9 @@ integrations:
- !reference [.rules:test:manual, rules]
ldap-no-server:
extends: .qa
extends:
- .qa
- .failure-videos
variables:
QA_SCENARIO: Test::Integration::LDAPNoServer
rules:
@ -410,7 +419,9 @@ ldap-no-server:
- !reference [.rules:test:manual, rules]
ldap-tls:
extends: .qa
extends:
- .qa
- .failure-videos
variables:
QA_SCENARIO: Test::Integration::LDAPTLS
rules:
@ -419,7 +430,9 @@ ldap-tls:
- !reference [.rules:test:manual, rules]
ldap-no-tls:
extends: .qa
extends:
- .qa
- .failure-videos
variables:
QA_SCENARIO: Test::Integration::LDAPNoTLS
rules:
@ -437,7 +450,9 @@ mtls:
- !reference [.rules:test:manual, rules]
mattermost:
extends: .qa
extends:
- .qa
- .failure-videos
variables:
QA_SCENARIO: Test::Integration::Mattermost
rules:
@ -446,7 +461,9 @@ mattermost:
- !reference [.rules:test:manual, rules]
registry:
extends: .qa
extends:
- .qa
- .failure-videos
variables:
QA_SCENARIO: Test::Integration::Registry
rules:
@ -455,7 +472,9 @@ registry:
- !reference [.rules:test:manual, rules]
registry-with-cdn:
extends: .qa
extends:
- .qa
- .failure-videos
variables:
QA_SCENARIO: Test::Integration::RegistryWithCDN
GCS_CDN_BUCKET_NAME: $QA_GCS_CDN_BUCKET_NAME
@ -472,7 +491,9 @@ registry-with-cdn:
- !reference [.rules:test:manual, rules]
repository-storage:
extends: .qa
extends:
- .qa
- .failure-videos
variables:
QA_SCENARIO: Test::Instance::RepositoryStorage
rules:
@ -481,7 +502,9 @@ repository-storage:
- !reference [.rules:test:manual, rules]
service-ping-disabled:
extends: .qa
extends:
- .qa
- .failure-videos
variables:
QA_SCENARIO: Test::Integration::ServicePingDisabled
rules:
@ -490,7 +513,9 @@ service-ping-disabled:
- !reference [.rules:test:manual, rules]
smtp:
extends: .qa
extends:
- .qa
- .failure-videos
variables:
QA_SCENARIO: Test::Integration::SMTP
rules:
@ -499,20 +524,21 @@ smtp:
- !reference [.rules:test:manual, rules]
cloud-activation:
extends: .qa
extends:
- .qa
- .failure-videos
variables:
QA_SCENARIO: Test::Instance::Image
QA_RSPEC_TAGS: --tag cloud_activation
USE_SELENOID: "true"
QA_RECORD_VIDEO: "true"
QA_REMOTE_GRID: "selenoid:4444"
rules:
- !reference [.rules:test:qa, rules]
- if: $QA_SUITES =~ /Test::Instance::CloudActivation/
- !reference [.rules:test:manual, rules]
large-setup:
extends: .qa
extends:
- .qa
- .failure-videos
variables:
QA_SCENARIO: Test::Instance::Image
QA_RSPEC_TAGS: --tag can_use_large_setup
@ -551,7 +577,9 @@ registry-object-storage-tls:
GITLAB_QA_OPTS: --omnibus-config registry_object_storage $EXTRA_GITLAB_QA_OPTS
importers:
extends: .qa
extends:
- .qa
- .failure-videos
variables:
QA_SCENARIO: Test::Integration::Import
QA_MOCK_GITHUB: "true"

6
.gitlab/ci/qa-common/main.gitlab-ci.yml
View File

@ -149,6 +149,12 @@ stages:
- bundle exec prepare-stage-reports --input-files "${QA_RSPEC_XML_FILE_PATTERN}"
- !reference [.notify-slack-qa, script]
.failure-videos:
variables:
USE_SELENOID: "true"
QA_RECORD_VIDEO: "true"
QA_REMOTE_GRID: "selenoid:4444"
# ==========================================
# Pre stage
# ==========================================

2
.rubocop_todo/layout/line_length.yml
View File

@ -1841,7 +1841,6 @@ Layout/LineLength:
- 'ee/spec/models/ee/iterations/cadence_spec.rb'
- 'ee/spec/models/ee/lfs_object_spec.rb'
- 'ee/spec/models/ee/merge_request_diff_spec.rb'
- 'ee/spec/models/ee/namespace/root_storage_statistics_spec.rb'
- 'ee/spec/models/ee/namespace_spec.rb'
- 'ee/spec/models/ee/namespace_statistics_spec.rb'
- 'ee/spec/models/ee/preloaders/group_policy_preloader_spec.rb'
@ -4256,7 +4255,6 @@ Layout/LineLength:
- 'spec/models/metrics/users_starred_dashboard_spec.rb'
- 'spec/models/milestone_spec.rb'
- 'spec/models/namespace/package_setting_spec.rb'
- 'spec/models/namespace/root_storage_statistics_spec.rb'
- 'spec/models/namespace_setting_spec.rb'
- 'spec/models/namespace_spec.rb'
- 'spec/models/namespace_statistics_spec.rb'

7
app/assets/javascripts/groups/components/overview_tabs.vue
View File

@ -3,6 +3,7 @@ import { GlTabs, GlTab, GlSearchBoxByType, GlSorting, GlSortingItem } from '@git
import { isString, debounce } from 'lodash';
import { __ } from '~/locale';
import { DEBOUNCE_DELAY } from '~/vue_shared/components/filtered_search_bar/constants';
import { markRaw } from '~/lib/utils/vue3compat/mark_raw';
import GroupsStore from '../store/groups_store';
import GroupsService from '../service/groups_service';
import ArchivedProjectsService from '../service/archived_projects_service';
@ -40,7 +41,7 @@ export default {
{
title: this.$options.i18n[ACTIVE_TAB_SUBGROUPS_AND_PROJECTS],
key: ACTIVE_TAB_SUBGROUPS_AND_PROJECTS,
emptyStateComponent: SubgroupsAndProjectsEmptyState,
emptyStateComponent: markRaw(SubgroupsAndProjectsEmptyState),
lazy: this.$route.name !== ACTIVE_TAB_SUBGROUPS_AND_PROJECTS,
service: new GroupsService(
this.endpoints[ACTIVE_TAB_SUBGROUPS_AND_PROJECTS],
@ -52,7 +53,7 @@ export default {
{
title: this.$options.i18n[ACTIVE_TAB_SHARED],
key: ACTIVE_TAB_SHARED,
emptyStateComponent: SharedProjectsEmptyState,
emptyStateComponent: markRaw(SharedProjectsEmptyState),
lazy: this.$route.name !== ACTIVE_TAB_SHARED,
service: new GroupsService(this.endpoints[ACTIVE_TAB_SHARED], this.initialSort),
store: new GroupsStore(),
@ -61,7 +62,7 @@ export default {
{
title: this.$options.i18n[ACTIVE_TAB_ARCHIVED],
key: ACTIVE_TAB_ARCHIVED,
emptyStateComponent: ArchivedProjectsEmptyState,
emptyStateComponent: markRaw(ArchivedProjectsEmptyState),
lazy: this.$route.name !== ACTIVE_TAB_ARCHIVED,
service: new ArchivedProjectsService(this.groupId, this.initialSort),
store: new GroupsStore(),

1
app/controllers/projects/issues_controller.rb
View File

@ -51,6 +51,7 @@ class Projects::IssuesController < Projects::ApplicationController
push_frontend_feature_flag(:service_desk_new_note_email_native_attachments, project)
push_frontend_feature_flag(:saved_replies, current_user)
push_frontend_feature_flag(:issues_grid_view)
push_frontend_feature_flag(:service_desk_ticket)
end
before_action only: [:index, :show] do

22
app/models/ai/service_access_token.rb Normal file
View File

@ -0,0 +1,22 @@
# frozen_string_literal: true
module Ai
class ServiceAccessToken < ApplicationRecord
self.table_name = 'service_access_tokens'
attr_encrypted :token,
mode: :per_attribute_iv,
key: Settings.attr_encrypted_db_key_base_32,
algorithm: 'aes-256-gcm',
encode: false,
encode_iv: false
validates :token, presence: true
enum category: {
code_suggestions: 1
}
validates :category, presence: true
end
end

8
config/feature_flags/development/service_desk_ticket.yml Normal file
View File

@ -0,0 +1,8 @@
---
name: service_desk_ticket
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/124681
rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/416343
milestone: '16.2'
type: development
group: group::respond
default_enabled: false

11
db/docs/service_access_tokens.yml Normal file
View File

@ -0,0 +1,11 @@
---
table_name: service_access_tokens
classes:
- Ai::ServiceAccessToken
feature_categories:
- application_performance
description: Persists JWT tokens for AI features (e.g. Code Suggestions) to authenticate
the GitLab instance
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/125383
milestone: '16.2'
gitlab_schema: gitlab_main

12
db/migrate/20230705085223_create_service_access_tokens.rb Normal file
View File

@ -0,0 +1,12 @@
# frozen_string_literal: true
class CreateServiceAccessTokens < Gitlab::Database::Migration[2.1]
def change
create_table :service_access_tokens do |t|
t.timestamps_with_timezone null: false
t.integer :category, limit: 2, null: false, default: 0
t.binary :encrypted_token, null: false
t.binary :encrypted_token_iv, null: false
end
end
end

1
db/schema_migrations/20230705085223 Normal file
View File

@ -0,0 +1 @@
dd4cb988fa1451dfac5f6c4ae0990be05472d1a8beee05fdd18a9bc137f07ee2

23
db/structure.sql
View File

@ -22667,6 +22667,24 @@ CREATE SEQUENCE sentry_issues_id_seq
ALTER SEQUENCE sentry_issues_id_seq OWNED BY sentry_issues.id;
CREATE TABLE service_access_tokens (
id bigint NOT NULL,
created_at timestamp with time zone NOT NULL,
updated_at timestamp with time zone NOT NULL,
category smallint DEFAULT 0 NOT NULL,
encrypted_token bytea NOT NULL,
encrypted_token_iv bytea NOT NULL
);
CREATE SEQUENCE service_access_tokens_id_seq
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1;
ALTER SEQUENCE service_access_tokens_id_seq OWNED BY service_access_tokens.id;
CREATE TABLE service_desk_custom_email_credentials (
project_id bigint NOT NULL,
created_at timestamp with time zone NOT NULL,
@ -25924,6 +25942,8 @@ ALTER TABLE ONLY sent_notifications ALTER COLUMN id SET DEFAULT nextval('sent_no
ALTER TABLE ONLY sentry_issues ALTER COLUMN id SET DEFAULT nextval('sentry_issues_id_seq'::regclass);
ALTER TABLE ONLY service_access_tokens ALTER COLUMN id SET DEFAULT nextval('service_access_tokens_id_seq'::regclass);
ALTER TABLE ONLY shards ALTER COLUMN id SET DEFAULT nextval('shards_id_seq'::regclass);
ALTER TABLE ONLY slack_api_scopes ALTER COLUMN id SET DEFAULT nextval('slack_api_scopes_id_seq'::regclass);
@ -28389,6 +28409,9 @@ ALTER TABLE ONLY sentry_issues
ALTER TABLE ONLY sprints
ADD CONSTRAINT sequence_is_unique_per_iterations_cadence_id UNIQUE (iterations_cadence_id, sequence) DEFERRABLE INITIALLY DEFERRED;
ALTER TABLE ONLY service_access_tokens
ADD CONSTRAINT service_access_tokens_pkey PRIMARY KEY (id);
ALTER TABLE ONLY service_desk_custom_email_credentials
ADD CONSTRAINT service_desk_custom_email_credentials_pkey PRIMARY KEY (project_id);

0
doc/user/admin_area/analytics/img/instance_activity_pipelines_chart_v13_6_a.png → doc/administration/analytics/img/instance_activity_pipelines_chart_v13_6_a.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 30 KiB

After

Width:  |  Height:  |  Size: 30 KiB

46
doc/administration/analytics/usage_trends.md Normal file
View File

@ -0,0 +1,46 @@
---
stage: Plan
group: Optimize
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
---
# Usage Trends **(FREE SELF)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/235754) in GitLab 13.5 behind a feature flag, disabled by default.
> - [Became enabled by default](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/46962) in GitLab 13.6.
> - [Renamed](https://gitlab.com/gitlab-org/gitlab/-/issues/285220) from Instance Statistics to Usage Trends in GitLab 13.6.
> - It's enabled on GitLab.com.
> - It's recommended for production use.
Usage Trends gives you an overview of how much data your instance contains, and how quickly this volume is changing over time.
Usage Trends data refreshes daily.
## View Usage Trends
To view Usage Trends:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Analytics > Usage Trends**.
## Total counts
At the top of the page, Usage Trends shows total counts for:
- Users
- Projects
- Groups
- Issues
- Merge requests
- Pipelines
These figures can be useful for understanding how much data your instance contains in total.
## Past year trend charts
Usage Trends also displays line charts that show total counts per month, over the past 12 months,
in the categories shown in [Total counts](#total-counts).
These charts help you visualize how rapidly these records are being created on your instance.
![Instance Activity Pipelines chart](img/instance_activity_pipelines_chart_v13_6_a.png)

123
doc/administration/appearance.md Normal file
View File

@ -0,0 +1,123 @@
---
stage: none
group: unassigned
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
---
# GitLab Appearance **(FREE SELF)**
Several options are available for customizing the appearance of a self-managed instance
of GitLab. To access these settings:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > Appearance**.
## Navigation bar
By default, the navigation bar has the GitLab logo, but this can be customized with
any image desired. It is optimized for images 28px high (any width), but any image can be
used (less than 1 MB) and it is automatically resized.
After you select and upload an image, select **Update appearance settings** at the bottom
of the page to activate it in the GitLab instance.
NOTE:
GitLab pipeline emails also display the custom logo, unless the logo is in SVG format. If the
custom logo is in SVG format, the default logo is used instead because the SVG format is not
supported by many email clients.
## Favicon
By default, the favicon (used by the browser as the tab icon, as well as the CI status icon)
uses the GitLab logo. This can be customized with any icon desired. It must be a
32x32 `.png` or `.ico` image.
After you select and upload an icon, select **Update appearance settings** at the bottom
of the page to activate it in the GitLab instance.
## System header and footer messages
> **Enable header and footer in emails** checkbox [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/344819) in GitLab 15.9.
You can add a small header message, a small footer message, or both, to the interface
of your GitLab instance. These messages appear on all projects and pages of the
instance, including the sign in / sign up page. The default color is white text on
an orange background, but this can be customized by selecting **Customize colors**.
Limited [Markdown](../user/markdown.md) is supported, such as bold, italics, and links, for
example. Other Markdown features, including lists, images, and quotes are not supported
as the header and footer messages can only be a single line.
You can select **Enable header and footer in emails** to have the text of
the header and footer added to all emails sent by the GitLab instance.
After you add a message, select **Update appearance settings** at the bottom of the page
to activate it in the GitLab instance.
## Sign in / Sign up pages
You can replace the default message on the sign in / sign up page with your own message
and logo. You can make full use of [Markdown](../user/markdown.md) in the description.
The optimal size for the logo is 128 x 128 pixels, but any image can be used (below 1 MB)
and it is resized automatically. The logo image appears between the title and
the description, on the left of the sign-up page.
After you add a message, select **Update appearance settings** at the bottom of the page
to activate it in the GitLab instance. You can also select **Sign-in page**,
to review the saved appearance settings:
NOTE:
You can add also add a [customized hcelp message](../user/admin_area/settings/help_page.md) below the sign in message or add [a Sign in text message](../user/admin_area/settings/sign_in_restrictions.md#sign-in-information).
## Progressive Web App
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/375708) in GitLab 15.9.
GitLab can be installed as a [Progressive Web App](https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps) (PWA).
Use the Progressive Web App settings to customize its appearance, including its name,
description, and icon.
### Configure the PWA settings
To configure the PWA settings:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > Appearance**.
1. Scroll to the **Progressive Web App (PWA)** section.
1. Complete the fields.
- **Icon**: If you use the standard GitLab icon, it is available in sizes 192x192 pixels,
512x512 pixels, also as a maskable icon. If you use a custom icon, it must be in either size
192x192 pixels, or 512x512 pixels.
1. Select **Update appearance settings**.
## New project pages
You can add a new project guidelines message to the **New project page** in GitLab.
You can make full use of [Markdown](../user/markdown.md) in the description:
The message is displayed below the **New Project** message, on the left side
of the **New project page**.
After you add a message, select **Update appearance settings** at the bottom of the page
to activate it in the GitLab instance. You can also select **New project page**,
which brings you to the new project page so you can review the change.
## Libravatar
[Libravatar](https://www.libravatar.org) is supported by GitLab for avatar images, but you must
[manually enable Libravatar support on the GitLab instance](../administration/libravatar.md) to use the service.
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, for example `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->

120
doc/administration/broadcast_messages.md Normal file
View File

@ -0,0 +1,120 @@
---
stage: Growth
group: Acquisition
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
type: reference, howto
---
# Broadcast messages **(FREE SELF)**
> - Target roles [introduced](https://gitlab.com/gitlab-org/growth/team-tasks/-/issues/461) in GitLab 14.8 [with a flag](../administration/feature_flags.md) named `role_targeted_broadcast_messages`. Disabled by default.
> - Theme [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/83251) and background color removed in GitLab 14.10.
GitLab can display broadcast messages to users of a GitLab instance. There are two types of broadcast messages:
- Banners
- Notifications
Broadcast messages can be managed using the [broadcast messages API](../api/broadcast_messages.md).
## Banners
Banners are shown on the top of a page and optionally in the command line as a Git remote response.
![Broadcast Message Banner](img/broadcast_messages_banner_v15_0.png)
```shell
$ git push
...
remote:
remote: **Welcome** to GitLab :wave:
remote:
...
```
If more than one banner is active at one time, they are displayed at the top of the page in order of creation. In the command line, only the latest banner is shown.
## Notifications
Notifications are shown on the bottom right of a page and can contain placeholders. A placeholder is replaced with an attribute of the active user. Placeholders must be surrounded by curly braces, for example `{{name}}`.
The available placeholders are:
- `{{email}}`
- `{{name}}`
- `{{user_id}}`
- `{{username}}`
- `{{instance_id}}`
If the user is not signed in, user related values are empty.
![Broadcast Message Notification](img/broadcast_messages_notification_v12_10.png)
If more than one notification is active at one time, only the newest is shown.
## Add a broadcast message
To display messages to users on your GitLab instance, add a broadcast message.
To add a broadcast message:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Messages**.
1. Add the text for the message to the **Message** field. You can style a message's content using Markdown, emoji, and the `a` and `br` HTML tags.
The `br` tag inserts a line break. The `a` HTML tag accepts `class` and `style` attributes with the following CSS properties:
- `color`
- `border`
- `background`
- `padding`
- `margin`
- `text-decoration`
1. Select a **Theme**. The default theme is `indigo`.
1. Select the **Dismissable** checkbox to enable users to dismiss the broadcast message.
1. Optional. Clear the **Git remote responses** checkbox to prevent broadcast messages from being displayed in the command line as Git remote responses.
1. Optional. Select **Target roles** to only show the broadcast message to users with the selected roles. The message displays on group, subgroup, and project pages, and does not display in Git remote responses.
1. If required, add a **Target Path** to only show the broadcast message on URLs matching that path. You can use the wildcard character `*` to match multiple URLs, for example `mygroup/myproject*`.
1. Select a date and time (UTC) for the message to start and end.
1. Select **Add broadcast message**.
When a broadcast message expires, it no longer displays in the user interface but is still listed in the
list of broadcast messages.
## Edit a broadcast message
If you must make changes to a broadcast message, you can edit it.
To edit a broadcast message:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Messages**.
1. From the list of broadcast messages, select the edit button for the message.
1. After making the required changes, select **Update broadcast message**.
Expired messages can be made active again by changing their end date.
## Delete a broadcast message
If you no longer require a broadcast message, you can delete it.
You can delete a broadcast message while it's active.
To delete a broadcast message:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Messages**.
1. From the list of broadcast messages, select the delete button for the message.
When a broadcast message is deleted, it's removed from the list of broadcast messages.
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, for example `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->

5
doc/administration/dedicated/index.md
View File

@ -68,8 +68,9 @@ To create a KMS key using the AWS Console:
1. Key material origin: **KMS**
1. Regionality: **Multi-Region key**
1. Enter your values for key alias, description, and tags.
1. Select Key administrators (optionally allow or deny key administrators to delete the key).
1. For Key usage permissions, add the GitLab AWS account using the **Other AWS accounts** dialog.
1. Select key administrators.
1. Optional. Allow or prevent key administrators from deleting the key.
1. On the **Define key usage permissions** page, under **Other AWS accounts**, add the GitLab AWS account.
The last page asks you to confirm the KMS key policy. It should look similar to the following example, populated with your account IDs and usernames:

0
doc/user/admin_area/img/broadcast_messages_banner_v15_0.png → doc/administration/img/broadcast_messages_banner_v15_0.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 13 KiB

After

Width:  |  Height:  |  Size: 13 KiB

0
doc/user/admin_area/img/broadcast_messages_notification_v12_10.png → doc/administration/img/broadcast_messages_notification_v12_10.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 23 KiB

After

Width:  |  Height:  |  Size: 23 KiB

27
doc/administration/settings/gitaly_timeouts.md Normal file
View File

@ -0,0 +1,27 @@
---
stage: Systems
group: Gitaly
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
---
# Gitaly timeouts **(FREE SELF)**
[Gitaly](../gitaly/index.md) timeouts are configurable. The timeouts can be
configured to make sure that long-running Gitaly calls don't needlessly take up resources.
To access Gitaly timeout settings:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > Preferences**.
1. Expand the **Gitaly timeouts** section.
## Available timeouts
The following timeouts are available.
| 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](../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. |
| 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. |

2
doc/administration/uploads.md
View File

@ -19,7 +19,7 @@ This is the default configuration. To change the location where the uploads are
stored locally, use the steps in this section based on your installation method:
NOTE:
For historical reasons, uploads for the whole instance (for example the [favicon](../user/admin_area/appearance.md#favicon)) are stored in a base directory,
For historical reasons, uploads for the whole instance (for example the [favicon](../administration/appearance.md#favicon)) are stored in a base directory,
which by default is `uploads/-/system`. Changing the base
directory on an existing GitLab installation is strongly discouraged.

4
doc/ci/environments/index.md
View File

@ -603,7 +603,7 @@ To stop an environment in the GitLab UI:
1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
1. Select **Operate > Environments**.
1. Next to the environment you want to stop, select **Stop**.
1. On the confirmation dialog box, select **Stop environment**.
1. On the confirmation dialog, select **Stop environment**.
#### Multiple stop actions for an environment
@ -668,7 +668,7 @@ To delete an environment:
1. Select **Operate > Environments**.
1. Select the **Stopped** tab.
1. Next to the environment you want to delete, select **Delete environment**.
1. On the confirmation dialog box, select **Delete environment**.
1. On the confirmation dialog, select **Delete environment**.
### Access an environment for preparation or verification purposes

10
doc/development/documentation/styleguide/word_list.md
View File

@ -324,10 +324,12 @@ Related terms:
## confirmation dialog
Use **confirmation dialog** to describe the dialog box that asks you to confirm your action. For example:
Use **confirmation dialog** to describe the dialog that asks you to confirm your action. For example:
- On the confirmation dialog, select **OK**.
Do not use **confirmation box** or **confirmation dialog box**.
## Container Registry
Use title case for the GitLab Container Registry.
@ -1478,9 +1480,9 @@ Use [**2FA** and **two-factor authentication**](#2fa-two-factor-authentication)
## type
Use **type** when the cursor remains in the field you're typing in. For example,
in a search dialog, you begin typing and the field populates results. You do not
click out of the field.
Use **type** when the cursor remains where you're typing. For example,
in a search box, you begin typing and search results appear. You do not
click out of the search box.
For example:

4
doc/development/gitaly.md
View File

@ -116,7 +116,7 @@ Please raise an issue in the GitLab CE or EE repositories to report the issue. I
~performance ~"technical debt". Please ensure that the issue contains the full stack trace and error message of the
`TooManyInvocationsError`. Also include any known failing tests if possible.
Isolate the source of the n+1 problem. This is normally a loop that results in Gitaly being called for each
Isolate the source of the n+1 problem. This is usually a loop that results in Gitaly being called for each
element in an array. If you are unable to isolate the problem, please contact a member
of the [Gitaly Team](https://gitlab.com/groups/gl-gitaly/group_members) for assistance.
@ -152,7 +152,7 @@ end
## Running tests with a locally modified version of Gitaly
Normally, GitLab CE/EE tests use a local clone of Gitaly in
Usually, GitLab CE/EE tests use a local clone of Gitaly in
`tmp/tests/gitaly` pinned at the version specified in
`GITALY_SERVER_VERSION`. The `GITALY_SERVER_VERSION` file supports also
branches and SHA to use a custom commit in [the repository](https://gitlab.com/gitlab-org/gitaly).

2
doc/development/graphql_guide/batchloader.md
View File

@ -161,7 +161,7 @@ you do so, you do not need to manage the lifecycle of lazy values yourself, and
you are assured accurate results.
GraphQL fields that return lazy values may need these values forced in tests.
Forcing refers to explicit demands for evaluation, where this would normally
Forcing refers to explicit demands for evaluation, where this would usually
be arranged by the framework.
You can force a lazy value with the `GraphqlHelpers#batch_sync` method available in [GraphQLHelpers](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/support/helpers/graphql_helpers.rb), or by using `Gitlab::Graphql::Lazy.force`. For example:

2
doc/development/internal_analytics/service_ping/implement.md
View File

@ -783,7 +783,7 @@ By default, it comes with a fully configured Prometheus service that is set up t
However, it has the following limitations:
- It does not run a `gitlab-exporter` instance, so several `process_*` metrics from services such as Gitaly may be missing.
- While it runs a `node_exporter`, `docker-compose` services emulate hosts, meaning that it normally reports itself as not associated
- While it runs a `node_exporter`, `docker-compose` services emulate hosts, meaning that it usually reports itself as not associated
with any of the other running services. That is not how node metrics are reported in a production setup, where `node_exporter`
always runs as a process alongside other GitLab components on any given node. For Service Ping, none of the node data would therefore
appear to be associated to any of the services running, because they all appear to be running on different hosts. To alleviate this problem, the `node_exporter` in GCK was arbitrarily "assigned" to the `web` service, meaning only for this service `node_*` metrics appears in Service Ping.

2
doc/development/performance.md
View File

@ -217,7 +217,7 @@ Finished in 18.19 seconds (files took 4.8 seconds to load)
```
You can limit the specs that are run by passing any arguments `RSpec` would
normally take.
usually take.
### Using Stackprof in production

2
doc/development/sidekiq/idempotent_jobs.md
View File

@ -156,7 +156,7 @@ end
## Setting the deduplication time-to-live (TTL)
Deduplication depends on an idempotent key that is stored in Redis. This is normally
Deduplication depends on an idempotent key that is stored in Redis. This is usually
cleared by the configured deduplication strategy.
However, the key can remain until its TTL in certain cases like:

2
doc/install/installation.md
View File

@ -174,7 +174,7 @@ the Git path:
### GraphicsMagick
For the [Custom Favicon](../user/admin_area/appearance.md#favicon) to work, GraphicsMagick
For the [Custom Favicon](../administration/appearance.md#favicon) to work, GraphicsMagick
must be installed.
```shell

3
doc/integration/advanced_search/elasticsearch.md
View File

@ -187,8 +187,7 @@ To enable advanced search:
1. Enable **Elasticsearch indexing** and select **Save changes**. This creates
an empty index if one does not already exist.
1. Select **Index all projects**.
1. Select **Check progress** in the confirmation message to see the status of
the background jobs.
1. Optional. Select **Check progress** to see the status of background jobs.
1. Personal snippets must be indexed using another Rake task:
```shell

2
doc/integration/jira/configure.md
View File

@ -81,7 +81,7 @@ To create a Jira Cloud API token:
profile, select **Account Settings > Security > Create and manage API tokens**.
1. Select **Create API token**.
1. In the dialog, enter a label for your token and select **Create**.
1. On the dialog, enter a label for your token and select **Create**.
To copy the API token, select **Copy**.

4
doc/integration/jira/jira_server_configuration.md
View File

@ -65,13 +65,13 @@ To create a permission scheme for the group:
1. On the top bar, in the upper-right corner, select **Administration** (**{settings}**) > **Issues**.
1. On the left sidebar, select **Permission schemes**.
1. Select **Add permission scheme**.
1. In the **Add permission scheme** dialog:
1. On the **Add permission scheme** dialog:
- Enter a name for the scheme.
- Optional. Enter a description for the scheme.
1. Select **Add**.
1. On the **Permission schemes** page, in the **Actions** column, select **Permissions** for the new scheme.
1. Next to **Administer Projects**, select **Edit**.
1. In the **Grant permission** dialog, for **Granted to**, select **Group**.
1. On the **Grant permission** dialog, for **Granted to**, select **Group**.
1. From the **Group** dropdown list, select `gitlab-developers`, then select **Grant**.
You've done it! You can now use your new Jira username and password to configure the

2
doc/policy/maintenance.md
View File

@ -102,7 +102,7 @@ accessible.
### Backporting to older releases
Backporting to more than one stable release is normally reserved for [security releases](#security-releases).
Backporting to more than one stable release is usually reserved for [security releases](#security-releases).
In some cases, however, we may need to backport *a bug fix* to more than one stable
release, depending on the severity of the bug.

49
doc/user/admin_area/analytics/usage_trends.md
View File

@ -1,46 +1,11 @@
---
stage: Plan
group: Optimize
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
redirect_to: '../../../administration/analytics/usage_trends.md'
remove_date: '2023-10-07'
---
# Usage Trends **(FREE SELF)**
This document was moved to [another location](../../../administration/analytics/usage_trends.md).
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/235754) in GitLab 13.5 behind a feature flag, disabled by default.
> - [Became enabled by default](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/46962) in GitLab 13.6.
> - [Renamed](https://gitlab.com/gitlab-org/gitlab/-/issues/285220) from Instance Statistics to Usage Trends in GitLab 13.6.
> - It's enabled on GitLab.com.
> - It's recommended for production use.
Usage Trends gives you an overview of how much data your instance contains, and how quickly this volume is changing over time.
Usage Trends data refreshes daily.
## View Usage Trends
To view Usage Trends:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Analytics > Usage Trends**.
## Total counts
At the top of the page, Usage Trends shows total counts for:
- Users
- Projects
- Groups
- Issues
- Merge requests
- Pipelines
These figures can be useful for understanding how much data your instance contains in total.
## Past year trend charts
Usage Trends also displays line charts that show total counts per month, over the past 12 months,
in the categories shown in [Total counts](#total-counts).
These charts help you visualize how rapidly these records are being created on your instance.
![Instance Activity Pipelines chart](img/instance_activity_pipelines_chart_v13_6_a.png)
<!-- This redirect file can be deleted after <2023-10-07>. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->

126
doc/user/admin_area/appearance.md
View File

@ -1,123 +1,11 @@
---
stage: none
group: unassigned
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
redirect_to: '../../administration/appearance.md'
remove_date: '2023-10-07'
---
# GitLab Appearance **(FREE SELF)**
This document was moved to [another location](../../administration/appearance.md).
Several options are available for customizing the appearance of a self-managed instance
of GitLab. To access these settings:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > Appearance**.
## Navigation bar
By default, the navigation bar has the GitLab logo, but this can be customized with
any image desired. It is optimized for images 28px high (any width), but any image can be
used (less than 1 MB) and it is automatically resized.
After you select and upload an image, select **Update appearance settings** at the bottom
of the page to activate it in the GitLab instance.
NOTE:
GitLab pipeline emails also display the custom logo, unless the logo is in SVG format. If the
custom logo is in SVG format, the default logo is used instead because the SVG format is not
supported by many email clients.
## Favicon
By default, the favicon (used by the browser as the tab icon, as well as the CI status icon)
uses the GitLab logo. This can be customized with any icon desired. It must be a
32x32 `.png` or `.ico` image.
After you select and upload an icon, select **Update appearance settings** at the bottom
of the page to activate it in the GitLab instance.
## System header and footer messages
> **Enable header and footer in emails** checkbox [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/344819) in GitLab 15.9.
You can add a small header message, a small footer message, or both, to the interface
of your GitLab instance. These messages appear on all projects and pages of the
instance, including the sign in / sign up page. The default color is white text on
an orange background, but this can be customized by selecting **Customize colors**.
Limited [Markdown](../markdown.md) is supported, such as bold, italics, and links, for
example. Other Markdown features, including lists, images, and quotes are not supported
as the header and footer messages can only be a single line.
You can select **Enable header and footer in emails** to have the text of
the header and footer added to all emails sent by the GitLab instance.
After you add a message, select **Update appearance settings** at the bottom of the page
to activate it in the GitLab instance.
## Sign in / Sign up pages
You can replace the default message on the sign in / sign up page with your own message
and logo. You can make full use of [Markdown](../markdown.md) in the description.
The optimal size for the logo is 128 x 128 pixels, but any image can be used (below 1 MB)
and it is resized automatically. The logo image appears between the title and
the description, on the left of the sign-up page.
After you add a message, select **Update appearance settings** at the bottom of the page
to activate it in the GitLab instance. You can also select **Sign-in page**,
to review the saved appearance settings:
NOTE:
You can add also add a [customized help message](settings/help_page.md) below the sign in message or add [a Sign in text message](settings/sign_in_restrictions.md#sign-in-information).
## Progressive Web App
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/375708) in GitLab 15.9.
GitLab can be installed as a [Progressive Web App](https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps) (PWA).
Use the Progressive Web App settings to customize its appearance, including its name,
description, and icon.
### Configure the PWA settings
To configure the PWA settings:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > Appearance**.
1. Scroll to the **Progressive Web App (PWA)** section.
1. Complete the fields.
- **Icon**: If you use the standard GitLab icon, it is available in sizes 192x192 pixels,
512x512 pixels, also as a maskable icon. If you use a custom icon, it must be in either size
192x192 pixels, or 512x512 pixels.
1. Select **Update appearance settings**.
## New project pages
You can add a new project guidelines message to the **New project page** in GitLab.
You can make full use of [Markdown](../markdown.md) in the description:
The message is displayed below the **New Project** message, on the left side
of the **New project page**.
After you add a message, select **Update appearance settings** at the bottom of the page
to activate it in the GitLab instance. You can also select **New project page**,
which brings you to the new project page so you can review the change.
## Libravatar
[Libravatar](https://www.libravatar.org) is supported by GitLab for avatar images, but you must
[manually enable Libravatar support on the GitLab instance](../../administration/libravatar.md) to use the service.
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, for example `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
<!-- This redirect file can be deleted after <2023-10-07>. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->

123
doc/user/admin_area/broadcast_messages.md
View File

@ -1,120 +1,11 @@
---
stage: Growth
group: Acquisition
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
type: reference, howto
redirect_to: '../../administration/broadcast_messages.md'
remove_date: '2023-10-07'
---
# Broadcast messages **(FREE SELF)**
This document was moved to [another location](../../administration/broadcast_messages.md).
> - Target roles [introduced](https://gitlab.com/gitlab-org/growth/team-tasks/-/issues/461) in GitLab 14.8 [with a flag](../../administration/feature_flags.md) named `role_targeted_broadcast_messages`. Disabled by default.
> - Theme [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/83251) and background color removed in GitLab 14.10.
GitLab can display broadcast messages to users of a GitLab instance. There are two types of broadcast messages:
- Banners
- Notifications
Broadcast messages can be managed using the [broadcast messages API](../../api/broadcast_messages.md).
## Banners
Banners are shown on the top of a page and optionally in the command line as a Git remote response.
![Broadcast Message Banner](img/broadcast_messages_banner_v15_0.png)
```shell
$ git push
...
remote:
remote: **Welcome** to GitLab :wave:
remote:
...
```
If more than one banner is active at one time, they are displayed at the top of the page in order of creation. In the command line, only the latest banner is shown.
## Notifications
Notifications are shown on the bottom right of a page and can contain placeholders. A placeholder is replaced with an attribute of the active user. Placeholders must be surrounded by curly braces, for example `{{name}}`.
The available placeholders are:
- `{{email}}`
- `{{name}}`
- `{{user_id}}`
- `{{username}}`
- `{{instance_id}}`
If the user is not signed in, user related values are empty.
![Broadcast Message Notification](img/broadcast_messages_notification_v12_10.png)
If more than one notification is active at one time, only the newest is shown.
## Add a broadcast message
To display messages to users on your GitLab instance, add a broadcast message.
To add a broadcast message:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Messages**.
1. Add the text for the message to the **Message** field. You can style a message's content using Markdown, emoji, and the `a` and `br` HTML tags.
The `br` tag inserts a line break. The `a` HTML tag accepts `class` and `style` attributes with the following CSS properties:
- `color`
- `border`
- `background`
- `padding`
- `margin`
- `text-decoration`
1. Select a **Theme**. The default theme is `indigo`.
1. Select the **Dismissable** checkbox to enable users to dismiss the broadcast message.
1. Optional. Clear the **Git remote responses** checkbox to prevent broadcast messages from being displayed in the command line as Git remote responses.
1. Optional. Select **Target roles** to only show the broadcast message to users with the selected roles. The message displays on group, subgroup, and project pages, and does not display in Git remote responses.
1. If required, add a **Target Path** to only show the broadcast message on URLs matching that path. You can use the wildcard character `*` to match multiple URLs, for example `mygroup/myproject*`.
1. Select a date and time (UTC) for the message to start and end.
1. Select **Add broadcast message**.
When a broadcast message expires, it no longer displays in the user interface but is still listed in the
list of broadcast messages.
## Edit a broadcast message
If you must make changes to a broadcast message, you can edit it.
To edit a broadcast message:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Messages**.
1. From the list of broadcast messages, select the edit button for the message.
1. After making the required changes, select **Update broadcast message**.
Expired messages can be made active again by changing their end date.
## Delete a broadcast message
If you no longer require a broadcast message, you can delete it.
You can delete a broadcast message while it's active.
To delete a broadcast message:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Messages**.
1. From the list of broadcast messages, select the delete button for the message.
When a broadcast message is deleted, it's removed from the list of broadcast messages.
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, for example `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
<!-- This redirect file can be deleted after <2023-10-07>. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->

2
doc/user/admin_area/settings/email.md
View File

@ -11,7 +11,7 @@ You can customize some of the content in emails sent from your GitLab instance.
## Custom logo
The logo in the header of some emails can be customized, see the [logo customization section](../appearance.md#navigation-bar).
The logo in the header of some emails can be customized, see the [logo customization section](../../../administration/appearance.md#navigation-bar).
## Include author name in email notification email body **(PREMIUM SELF)**

30
doc/user/admin_area/settings/gitaly_timeouts.md
View File

@ -1,27 +1,11 @@
---
stage: Systems
group: Gitaly
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
redirect_to: '../../../administration/settings/gitaly_timeouts.md'
remove_date: '2023-10-07'
---
# Gitaly timeouts **(FREE SELF)**
This document was moved to [another location](../../../administration/settings/gitaly_timeouts.md).
[Gitaly](../../../administration/gitaly/index.md) timeouts are configurable. The timeouts can be
configured to make sure that long-running Gitaly calls don't needlessly take up resources.
To access Gitaly timeout settings:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > Preferences**.
1. Expand the **Gitaly timeouts** section.
## Available timeouts
The following timeouts are available.
| 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#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. |
| 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. |
<!-- This redirect file can be deleted after <2023-10-07>. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->

4
doc/user/group/epics/epic_boards.md
View File

@ -107,8 +107,8 @@ To remove a list from an epic board:
1. On the top of the list you want to remove, select the **List settings** icon (**{settings}**).
The list settings sidebar opens on the right.
1. Select **Remove list**. A confirmation dialog appears.
1. Select **OK**.
1. Select **Remove list**.
1. On the confirmation dialog, select **OK**.
### Create an epic from an epic board

2
doc/user/packages/container_registry/delete_container_registry_images.md
View File

@ -45,7 +45,7 @@ To delete container images using the GitLab UI:
by selecting the red **{remove}** **Trash** icon next to the tag you want
to delete.
1. In the dialog box, select **Remove tag**.
1. On the dialog, select **Remove tag**.
## Use the GitLab API

2
doc/user/profile/contributions_calendar.md
View File

@ -101,6 +101,6 @@ To reset your feed token:
1. On the left sidebar, select **Access Tokens**.
1. Scroll down. In the **Feed token** section, select the
**reset this token** link.
1. On the confirmation box, select **OK**.
1. On the confirmation dialog, select **OK**.
A new token is generated.

4
doc/user/project/file_lock.md
View File

@ -147,7 +147,7 @@ permissions to the project:
git lfs unlock --id=123 --force
```
You can normally push files to GitLab whether they're locked or unlocked.
You can push files to GitLab whether they're locked or unlocked.
NOTE:
Although multi-branch file locks can be created and managed through the Git LFS
@ -209,7 +209,7 @@ To lock a file:
1. Open the file or directory in GitLab.
1. In the upper-right corner, above the file, select **Lock**.
1. On the confirmation dialog box, select **OK**.
1. On the confirmation dialog, select **OK**.
If you do not have permission to lock the file, the button is not enabled.

4
doc/user/project/issue_board.md
View File

@ -501,8 +501,8 @@ To remove a list from an issue board:
1. On the top of the list you want to remove, select **List actions** (**{ellipsis_v}**).
The list settings sidebar opens on the right.
1. Select **Remove list**. A confirmation dialog appears.
1. Select **Remove list** again.
1. Select **Remove list**.
1. On the confirmation dialog, select **Remove list** again.
### Add issues to a list

2
doc/user/project/issues/design_management.md
View File

@ -251,7 +251,7 @@ Prerequisites:
To delete a comment from a design:
1. On the comment you want to delete, select **More actions** **{ellipsis_v}** **> Delete comment**.
1. On the confirmation dialog box, select **Delete comment**.
1. On the confirmation dialog, select **Delete comment**.
## Resolve a discussion thread on a design

2
doc/user/project/members/index.md
View File

@ -235,7 +235,7 @@ To remove a member from a project:
1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
1. Select **Manage > Members**.
1. Next to the project member you want to remove, select **Remove member**.
1. Optional. In the confirmation box, select the
1. Optional. On the confirmation dialog, select the
**Also unassign this user from related issues and merge requests** checkbox.
1. To prevent leaks of sensitive information from private projects, verify the
member has not forked the private repository or created webhooks. Existing forks continue to receive

3
doc/user/project/protected_branches.md
View File

@ -360,8 +360,7 @@ branches by using the GitLab web interface:
1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
1. Select **Code > Branches**.
1. Next to the branch you want to delete, select **Delete** (**{remove}**).
1. On the confirmation dialog, type the branch name.
1. Select **Yes, delete protected branch**.
1. On the confirmation dialog, enter the branch name and select **Yes, delete protected branch**.
Protected branches can only be deleted by using GitLab either from the UI or API.
This prevents accidentally deleting a branch through local Git commands or

2
doc/user/project/releases/release_evidence.md
View File

@ -97,7 +97,7 @@ Evidence collection snapshots are visible on the Releases page, along with the t
When you create a release, if [job artifacts](../../../ci/yaml/index.md#artifactsreports) are included in the last pipeline that ran, they are automatically included in the release as release evidence.
Although job artifacts normally expire, artifacts included in release evidence do not expire.
Although job artifacts usually expire, artifacts included in release evidence do not expire.
To enable job artifact collection you must specify both:

2
doc/user/project/service_desk.md
View File

@ -142,7 +142,7 @@ Instance administrators can add a header, footer or additional text to the GitLa
them to all emails sent from GitLab. If you're using a custom `thank_you.md` or `new_note.md`, to include
this content, add `%{SYSTEM_HEADER}`, `%{SYSTEM_FOOTER}`, or `%{ADDITIONAL_TEXT}` to your templates.
For more information, see [System header and footer messages](../admin_area/appearance.md#system-header-and-footer-messages) and [custom additional text](../admin_area/settings/email.md#custom-additional-text).
For more information, see [System header and footer messages](../../administration/appearance.md#system-header-and-footer-messages) and [custom additional text](../admin_area/settings/email.md#custom-additional-text).
### Use a custom template for Service Desk tickets

4
doc/user/project/settings/index.md
View File

@ -308,7 +308,7 @@ To delete a project:
1. Select **Settings > General**.
1. Expand **Advanced**.
1. In the **Delete this project** section, select **Delete project**.
1. In the confirmation message text field, enter the name of the project as instructed, and select **Yes, delete project**.
1. On the confirmation dialog, enter the project name and select **Yes, delete project**.
This action deletes the project and all associated resources (such as issues and merge requests).
@ -344,7 +344,7 @@ To immediately delete a project marked for deletion:
1. Select **Settings > General**.
1. Expand **Advanced**.
1. In the **Delete this project** section, select **Delete project**.
1. In the confirmation message text field, enter the name of the project as instructed, as select **Yes, delete project**.
1. On the confirmation dialog, enter the project name and select **Yes, delete project**.
## Restore a project **(PREMIUM)**

20
spec/features/issues/service_desk_spec.rb
View File

@ -206,5 +206,25 @@ RSpec.describe 'Service Desk Issue Tracker', :js, feature_category: :team_planni
end
end
end
context 'for feature flags' do
let(:service_desk_issue) { create(:issue, project: project, author: support_bot, service_desk_reply_to: 'service.desk@example.com') }
before do
visit project_issue_path(project, service_desk_issue)
end
it 'pushes the service_desk_ticket feature flag to frontend when available' do
stub_feature_flags(service_desk_ticket: true)
expect(page).to have_pushed_frontend_feature_flags(serviceDeskTicket: true)
end
it 'does not push the service_desk_ticket feature flag to frontend when not available' do
stub_feature_flags(service_desk_ticket: false)
expect(page).not_to have_pushed_frontend_feature_flags(serviceDeskTicket: false)
end
end
end
end

25
spec/models/ai/service_access_token_spec.rb Normal file
View File

@ -0,0 +1,25 @@
# frozen_string_literal: true
require 'spec_helper'
RSpec.describe Ai::ServiceAccessToken, type: :model, feature_category: :application_performance do
describe '#token' do
let(:token_value) { 'Abc' }
it 'is encrypted' do
subject.token = token_value
aggregate_failures do
expect(subject.encrypted_token_iv).to be_present
expect(subject.encrypted_token).to be_present
expect(subject.encrypted_token).not_to eq(token_value)
expect(subject.token).to eq(token_value)
end
end
describe 'validations' do
it { is_expected.to validate_presence_of(:token) }
it { is_expected.to validate_presence_of(:category) }
end
end
end

39
spec/models/namespace/root_storage_statistics_spec.rb
View File

@ -2,7 +2,7 @@
require 'spec_helper'
RSpec.describe Namespace::RootStorageStatistics, type: :model do
RSpec.describe Namespace::RootStorageStatistics, type: :model, feature_category: :consumables_cost_management do
it { is_expected.to belong_to :namespace }
it { is_expected.to have_one(:route).through(:namespace) }
@ -123,10 +123,21 @@ RSpec.describe Namespace::RootStorageStatistics, type: :model do
let_it_be(:group1) { create(:group, parent: root_group) }
let_it_be(:subgroup1) { create(:group, parent: group1) }
let_it_be(:group2) { create(:group, parent: root_group) }
let_it_be(:root_namespace_stat) { create(:namespace_statistics, namespace: root_group, storage_size: 100, dependency_proxy_size: 100) }
let_it_be(:group1_namespace_stat) { create(:namespace_statistics, namespace: group1, storage_size: 200, dependency_proxy_size: 200) }
let_it_be(:group2_namespace_stat) { create(:namespace_statistics, namespace: group2, storage_size: 300, dependency_proxy_size: 300) }
let_it_be(:subgroup1_namespace_stat) { create(:namespace_statistics, namespace: subgroup1, storage_size: 300, dependency_proxy_size: 100) }
let_it_be(:root_namespace_stat) do
create(:namespace_statistics, namespace: root_group, storage_size: 100, dependency_proxy_size: 100)
end
let_it_be(:group1_namespace_stat) do
create(:namespace_statistics, namespace: group1, storage_size: 200, dependency_proxy_size: 200)
end
let_it_be(:group2_namespace_stat) do
create(:namespace_statistics, namespace: group2, storage_size: 300, dependency_proxy_size: 300)
end
let_it_be(:subgroup1_namespace_stat) do
create(:namespace_statistics, namespace: subgroup1, storage_size: 300, dependency_proxy_size: 100)
end
let(:namespace) { root_group }
@ -148,8 +159,12 @@ RSpec.describe Namespace::RootStorageStatistics, type: :model do
total_pipeline_artifacts_size = project_stat1.pipeline_artifacts_size + project_stat2.pipeline_artifacts_size
total_uploads_size = project_stat1.uploads_size + project_stat2.uploads_size
total_wiki_size = project_stat1.wiki_size + project_stat2.wiki_size
total_dependency_proxy_size = root_namespace_stat.dependency_proxy_size + group1_namespace_stat.dependency_proxy_size + group2_namespace_stat.dependency_proxy_size + subgroup1_namespace_stat.dependency_proxy_size
total_storage_size = project_stat1.storage_size + project_stat2.storage_size + root_namespace_stat.storage_size + group1_namespace_stat.storage_size + group2_namespace_stat.storage_size + subgroup1_namespace_stat.storage_size
total_dependency_proxy_size = root_namespace_stat.dependency_proxy_size +
group1_namespace_stat.dependency_proxy_size + group2_namespace_stat.dependency_proxy_size +
subgroup1_namespace_stat.dependency_proxy_size
total_storage_size = project_stat1.storage_size + project_stat2.storage_size +
root_namespace_stat.storage_size + group1_namespace_stat.storage_size +
group2_namespace_stat.storage_size + subgroup1_namespace_stat.storage_size
expect(root_storage_statistics.repository_size).to eq(total_repository_size)
expect(root_storage_statistics.lfs_objects_size).to eq(total_lfs_objects_size)
@ -209,7 +224,8 @@ RSpec.describe Namespace::RootStorageStatistics, type: :model do
root_storage_statistics.recalculate!
expect(root_storage_statistics.snippets_size).to eq(total_personal_snippets_size + total_project_snippets_size)
total = total_personal_snippets_size + total_project_snippets_size
expect(root_storage_statistics.snippets_size).to eq(total)
end
context 'when personal snippets do not have statistics' do
@ -219,7 +235,8 @@ RSpec.describe Namespace::RootStorageStatistics, type: :model do
root_storage_statistics.recalculate!
expect(root_storage_statistics.snippets_size).to eq(total_project_snippets_size + snippets.last.statistics.repository_size)
total = total_project_snippets_size + snippets.last.statistics.repository_size
expect(root_storage_statistics.snippets_size).to eq(total)
end
end
end
@ -293,7 +310,9 @@ RSpec.describe Namespace::RootStorageStatistics, type: :model do
root_storage_statistics.reload
expect(root_storage_statistics.private_forks_storage_size).to eq(project_fork.statistics.storage_size)
expect(root_storage_statistics.storage_size).to eq(project.statistics.storage_size + project_fork.statistics.storage_size)
total = project.statistics.storage_size + project_fork.statistics.storage_size
expect(root_storage_statistics.storage_size).to eq(total)
end
it 'sets the public forks storage size back to zero' do