Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2023-07-14 12:10:12 +00:00
parent 7a7f602c26
commit 14a0edee5c
78 changed files with 688 additions and 429 deletions

View File

@ -72,6 +72,7 @@ GITALY_SERVER_VERSION @project_278964_bot6 @gitlab-org/maintainers/rails-backend
/.gitlab/ci/test-on-gdk/ @gl-quality/eng-prod @gl-quality/qe-maintainers
Dangerfile
/danger/
/gems/gem.gitlab-ci.yml
/tooling/danger/
/scripts/
/scripts/frontend/ @gl-quality/eng-prod @gitlab-org/maintainers/frontend
@ -81,6 +82,7 @@ Dangerfile
^[Backend Static Code Analysis] @gl-quality/eng-prod @dstull @splattael
.rubocop*.yml
.rubocop_todo/
/gems/config/rubocop.yml
/rubocop/
/spec/rubocop/

View File

@ -220,7 +220,7 @@
.db-services:
services: &db-services
- name: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images:postgres-${PG_VERSION}-pgvector-0.4.1
command: ["postgres", "-c", "fsync=off", "-c", "synchronous_commit=off", "-c", "full_page_writes=off", "-c", "max_locks_per_transaction=128"]
command: ["postgres", "-c", "fsync=off", "-c", "synchronous_commit=off", "-c", "full_page_writes=off", "-c", "max_locks_per_transaction=256"]
alias: postgres
- name: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images:redis-cluster-6.2.12
alias: rediscluster # configure connections in config/redis.yml

View File

@ -1 +1 @@
f2c232b9898c255cff523240d7f53b77ae698e74
4c314694734330f910ce5d1409c0d462a02628ff

View File

@ -2,7 +2,7 @@
import { GlIcon, GlDropdown, GlSearchBoxByType } from '@gitlab/ui';
import { findLastIndex } from 'lodash';
import VirtualList from 'vue-virtual-scroll-list';
import { CATEGORY_NAMES, getEmojiCategoryMap } from '~/emoji';
import { CATEGORY_NAMES, getEmojiCategoryMap, state } from '~/emoji';
import { CATEGORY_ICON_MAP, FREQUENTLY_USED_KEY } from '../constants';
import Category from './category.vue';
import EmojiList from './emoji_list.vue';
@ -49,7 +49,7 @@ export default {
categoryNames() {
return CATEGORY_NAMES.filter((c) => {
if (c === FREQUENTLY_USED_KEY) return hasFrequentlyUsedEmojis();
if (c === 'custom') return getEmojiCategoryMap()?.custom.length > 0;
if (c === 'custom') return !state.loading && getEmojiCategoryMap().custom.length > 0;
return true;
}).map((category) => ({
name: category,

View File

@ -1,3 +1,4 @@
import Vue from 'vue';
import { escape, minBy } from 'lodash';
import emojiRegexFactory from 'emoji-regex';
import emojiAliases from 'emojis/aliases.json';
@ -12,6 +13,10 @@ import { CACHE_KEY, CACHE_VERSION_KEY, CATEGORY_ICON_MAP, FREQUENTLY_USED_KEY }
let emojiMap = null;
let validEmojiNames = null;
export const state = Vue.observable({
loading: true,
});
export const FALLBACK_EMOJI_KEY = 'grey_question';
// Keep the version in sync with `lib/gitlab/emoji.rb`
@ -91,6 +96,7 @@ async function prepareEmojiMap() {
...values[1],
};
validEmojiNames = [...Object.keys(emojiMap), ...Object.keys(emojiAliases)];
state.loading = false;
});
}

View File

@ -426,7 +426,7 @@ export default {
</gl-button>
<gl-button
v-if="showToggleIssueStateButton"
v-if="showToggleIssueStateButton && !glFeatures.moveCloseIntoDropdown"
class="gl-display-none gl-sm-display-inline-flex!"
:data-qa-selector="qaSelector"
:loading="isToggleStateButtonLoading"
@ -462,7 +462,12 @@ export default {
<gl-dropdown-divider />
</template>
<gl-dropdown-item
v-if="showToggleIssueStateButton && glFeatures.moveCloseIntoDropdown"
@click="toggleIssueState"
>
{{ buttonText }}
</gl-dropdown-item>
<gl-dropdown-item v-if="canCreateIssue && isUserSignedIn" :href="newIssuePath">
{{ newIssueTypeText }}
</gl-dropdown-item>
@ -492,6 +497,7 @@ export default {
>{{ copyMailAddressText }}</gl-dropdown-item
>
</template>
<gl-dropdown-divider v-if="showToggleIssueStateButton || canDestroyIssue || canReportSpam" />
<gl-dropdown-item
v-if="canReportSpam"
:href="submitAsSpamPath"
@ -500,8 +506,14 @@ export default {
>
{{ __('Submit as spam') }}
</gl-dropdown-item>
<gl-dropdown-item
v-if="!isIssueAuthor && isUserSignedIn"
data-testid="report-abuse-item"
@click="toggleReportAbuseDrawer(true)"
>
{{ $options.i18n.reportAbuse }}
</gl-dropdown-item>
<template v-if="canDestroyIssue">
<gl-dropdown-divider />
<gl-dropdown-item
v-gl-modal="$options.deleteModalId"
variant="danger"
@ -511,13 +523,6 @@ export default {
{{ deleteButtonText }}
</gl-dropdown-item>
</template>
<gl-dropdown-item
v-if="!isIssueAuthor && isUserSignedIn"
data-testid="report-abuse-item"
@click="toggleReportAbuseDrawer(true)"
>
{{ $options.i18n.reportAbuse }}
</gl-dropdown-item>
</gl-dropdown>
<new-header-actions-popover v-if="isMrSidebarMoved" :issue-type="issueType" />

View File

@ -111,7 +111,11 @@ export default {
/>
<p class="gl-mb-3">
{{ s__('JiraConnect|Not seeing your groups? Only groups you have access to appear here.') }}
{{
s__(
'JiraConnect|Not seeing your groups? Only groups you have at least the Maintainer role for appear here.',
)
}}
</p>
<gl-loading-icon v-if="isLoadingInitial" size="lg" />

View File

@ -19,7 +19,7 @@ export default {
},
computed: {
...mapState(['query', 'groups', 'fetchingGroups']),
...mapGetters(['frequentGroups']),
...mapGetters(['frequentGroups', 'currentScope']),
selectedGroup() {
return isEmpty(this.initialData) ? ANY_OPTION : this.initialData;
},
@ -43,6 +43,7 @@ export default {
[GROUP_DATA.queryParam]: group.id,
[PROJECT_DATA.queryParam]: null,
nav_source: null,
scope: this.currentScope,
}),
);
},

View File

@ -18,7 +18,7 @@ export default {
},
computed: {
...mapState(['query', 'projects', 'fetchingProjects']),
...mapGetters(['frequentProjects']),
...mapGetters(['frequentProjects', 'currentScope']),
selectedProject() {
return this.initialData ? this.initialData : ANY_OPTION;
},
@ -42,6 +42,7 @@ export default {
...(project.namespace?.id && { [GROUP_DATA.queryParam]: project.namespace.id }),
[PROJECT_DATA.queryParam]: project.id,
nav_source: null,
scope: this.currentScope,
};
visitUrl(setUrlParams(queryParams));

View File

@ -11,6 +11,7 @@ class Projects::IncidentsController < Projects::ApplicationController
push_force_frontend_feature_flag(:work_items_mvc, @project&.work_items_mvc_feature_flag_enabled?)
push_force_frontend_feature_flag(:work_items_mvc_2, @project&.work_items_mvc_2_feature_flag_enabled?)
push_frontend_feature_flag(:moved_mr_sidebar, project)
push_frontend_feature_flag(:move_close_into_dropdown, project)
end
feature_category :incident_management

View File

@ -70,6 +70,7 @@ class Projects::IssuesController < Projects::ApplicationController
push_force_frontend_feature_flag(:work_items_mvc_2, project&.work_items_mvc_2_feature_flag_enabled?)
push_frontend_feature_flag(:epic_widget_edit_confirmation, project)
push_frontend_feature_flag(:moved_mr_sidebar, project)
push_frontend_feature_flag(:move_close_into_dropdown, project)
end
around_action :allow_gitaly_ref_name_caching, only: [:discussions]

View File

@ -11,6 +11,11 @@ module ResolvesMergeRequests
end
def resolve_with_lookahead(**args)
if args[:group_id]
args[:group_id] = ::GitlabSchema.parse_gid(args[:group_id], expected_type: ::Group).model_id
args[:include_subgroups] = true
end
mr_finder = MergeRequestsFinder.new(current_user, args.compact)
finder = Gitlab::Graphql::Loaders::IssuableLoader.new(mr_parent, mr_finder)

View File

@ -4,6 +4,14 @@ module Resolvers
class UserMergeRequestsResolverBase < MergeRequestsResolver
include ResolvesProject
argument :group_id,
type: ::Types::GlobalIDType[::Group],
required: false,
description: <<~DESC
The global ID of the group the authored merge requests should be in.
Merge requests in subgroups are included.
DESC
argument :project_path,
type: GraphQL::Types::String,
required: false,

View File

@ -4,7 +4,9 @@ module ColorsHelper
HEX_COLOR_PATTERN = /\A\#(?:[0-9A-Fa-f]{3}){1,2}\Z/.freeze
def hex_color_to_rgb_array(hex_color)
raise ArgumentError, "invalid hex color `#{hex_color}`" unless hex_color =~ HEX_COLOR_PATTERN
unless hex_color.is_a?(String) && hex_color =~ HEX_COLOR_PATTERN
raise ArgumentError, "invalid hex color `#{hex_color}`"
end
hex_color.length == 7 ? hex_color[1, 7].scan(/.{2}/).map(&:hex) : hex_color[1, 4].scan(/./).map { |v| (v * 2).hex }
end

View File

@ -5,7 +5,7 @@ module JiraConnectHelper
skip_groups = subscriptions.map(&:namespace_id)
{
groups_path: api_v4_groups_path(params: { all_available: true, skip_groups: skip_groups }),
groups_path: api_v4_groups_path(params: { min_access_level: Gitlab::Access::MAINTAINER, skip_groups: skip_groups }),
subscriptions: subscriptions.map { |s| serialize_subscription(s) }.to_json,
subscriptions_path: jira_connect_subscriptions_path(format: :json),
gitlab_user_path: current_user ? user_path(current_user) : nil,

View File

@ -32,7 +32,7 @@
= f.label :admin_mode, _('Admin mode'), class: 'label-bold'
= sprite_icon('lock', css_class: 'gl-icon')
- help_text = _('Require additional authentication for administrative tasks.')
- help_link = link_to _('Learn more.'), help_page_path('user/admin_area/settings/sign_in_restrictions', anchor: 'admin-mode'), target: '_blank', rel: 'noopener noreferrer'
- help_link = link_to _('Learn more.'), help_page_path('administration/settings/sign_in_restrictions', anchor: 'admin-mode'), target: '_blank', rel: 'noopener noreferrer'
= f.gitlab_ui_checkbox_component :admin_mode,
_('Enable admin mode'),
help_text: '%{help_text} %{help_link}'.html_safe % { help_text: help_text, help_link: help_link }

View File

@ -53,7 +53,7 @@
- if params[:action_id].present?
= hidden_field_tag(:action_id, params[:action_id])
= dropdown_tag(todo_actions_dropdown_label(params[:action_id], _("Action")), options: { toggle_class: 'js-action-search js-filter-submit gl-xs-w-full!', dropdown_class: 'dropdown-menu-selectable dropdown-menu-action js-filter-submit', data: { data: todo_actions_options, default_label: _("Action") } })
.filter-item.sort-filter.gl-mt-3.gl-sm-mt-0.gl-mb-0.gl-sm-mb-0
.filter-item.sort-filter.gl-my-2
.dropdown
%button.dropdown-menu-toggle.dropdown-menu-toggle-sort{ type: 'button', class: 'gl-xs-w-full!', 'data-toggle' => 'dropdown' }
%span.light

View File

@ -3,7 +3,7 @@
- if can?(current_user, :download_code, @project)
.git-clone-holder.js-git-clone-holder
%a#clone-dropdown.gl-button.btn.btn-confirm.clone-dropdown-btn{ href: '#', data: { toggle: 'dropdown', qa_selector: 'clone_dropdown' } }
= render Pajamas::ButtonComponent.new(variant: :confirm, button_options: { id: 'clone-dropdown', class: 'clone-dropdown-btn', data: { toggle: 'dropdown', qa_selector: 'clone_dropdown' } }) do
%span.gl-mr-2.js-clone-dropdown-label
= _('Clone')
= sprite_icon("chevron-down", css_class: "icon")

View File

@ -6,7 +6,7 @@
- if !project.empty_repo? && can?(current_user, :download_code, project)
- archive_prefix = "#{project.path}-#{ref.tr('/', '-')}"
.project-action-button.dropdown.gl-dropdown.inline{ class: css_class }>
%button.gl-button.btn.btn-default.dropdown-toggle.gl-dropdown-toggle.dropdown-icon-only.has-tooltip{ title: s_('DownloadSource|Download'), 'data-toggle' => 'dropdown', 'aria-label' => s_('DownloadSource|Download'), 'data-display' => 'static', data: { qa_selector: 'download_source_code_button' } }
= render Pajamas::ButtonComponent.new(button_options: { class: 'dropdown-toggle gl-dropdown-toggle dropdown-icon-only has-tooltip', title: s_('DownloadSource|Download'), 'data-toggle' => 'dropdown', 'aria-label' => s_('DownloadSource|Download'), 'data-display' => 'static', data: { qa_selector: 'download_source_code_button' } }) do
= sprite_icon('download', css_class: 'gl-icon dropdown-icon')
%span.sr-only= _('Select Archive Format')
= sprite_icon('chevron-down', css_class: 'gl-icon dropdown-chevron')

View File

@ -15,7 +15,7 @@
%aside.right-sidebar.js-right-sidebar.js-issuable-sidebar{ data: { always_show_toggle: true, signed: { in: signed_in }, issuable_type: issuable_type }, class: "#{sidebar_gutter_collapsed_class(is_merge_request_with_flag)} #{'right-sidebar-merge-requests' if is_merge_request_with_flag}", 'aria-live' => 'polite', 'aria-label': issuable_type }
.issuable-sidebar{ class: "#{'is-merge-request' if is_merge_request_with_flag}" }
.issuable-sidebar-header{ class: "#{'gl-pb-2! gl-md-display-flex gl-justify-content-end gl-lg-display-none!' if is_merge_request_with_flag}" }
%button.btn.gl-button.gutter-toggle.float-right.js-sidebar-toggle.has-tooltip{ type: "reset", class: "gl-shadow-none! #{'gl-display-block' if moved_sidebar_enabled}", "aria-label" => _('Toggle sidebar'), title: sidebar_gutter_tooltip_text, data: { container: 'body', placement: 'left', boundary: 'viewport' } }
= render Pajamas::ButtonComponent.new(button_options: { class: "gutter-toggle float-right js-sidebar-toggle has-tooltip gl-shadow-none! #{'gl-display-block' if moved_sidebar_enabled}", type: 'button', 'aria-label' => _('Toggle sidebar'), title: sidebar_gutter_tooltip_text, data: { container: 'body', placement: 'left', boundary: 'viewport' } }) do
= sidebar_gutter_toggle_icon
- if signed_in && !is_merge_request_with_flag
.js-sidebar-todo-widget-root{ data: { project_path: issuable_sidebar[:project_full_path], iid: issuable_sidebar[:iid], id: issuable_sidebar[:id] } }

View File

@ -0,0 +1,8 @@
---
name: move_close_into_dropdown
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/125173
rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/416861
milestone: '16.2'
type: development
group: group::ux paper cuts
default_enabled: false

View File

@ -69,7 +69,7 @@ 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).
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](settings/sign_in_restrictions.md#sign-in-information).
## Progressive Web App

View File

@ -25,7 +25,7 @@ Users added through LDAP:
- Usually use a [licensed seat](../../../subscriptions/self_managed/index.md#billable-users).
- Can authenticate with Git using either their GitLab username or their email and LDAP password,
even if password authentication for Git
[is disabled](../../../user/admin_area/settings/sign_in_restrictions.md#password-authentication-enabled).
[is disabled](../../settings/sign_in_restrictions.md#password-authentication-enabled).
The LDAP DN is associated with existing GitLab users when:

View File

@ -17,7 +17,7 @@ By default, existing users can continue to sign in with a username and password
authentication is enabled.
To force existing users to use only smartcard authentication,
[disable username and password authentication](../../user/admin_area/settings/sign_in_restrictions.md#password-authentication-enabled).
[disable username and password authentication](../settings/sign_in_restrictions.md#password-authentication-enabled).
## Authentication methods

View File

@ -218,7 +218,7 @@ If you try to view replication data on the primary site, you receive a warning t
The only way to view projects replication data for a particular secondary site is to visit that secondary site directly. For example, `https://<IP of your secondary site>/admin/geo/replication/projects`.
An [epic exists](https://gitlab.com/groups/gitlab-org/-/epics/4623) to fix this limitation.
Keep in mind that mentioned URLs don't work when [Admin Mode](../../user/admin_area/settings/sign_in_restrictions.md#admin-mode) is enabled.
Keep in mind that mentioned URLs don't work when [Admin Mode](../settings/sign_in_restrictions.md#admin-mode) is enabled.
When using Unified URL, visiting the secondary site directly means you must route your requests to the secondary site. Exactly how this might be done depends on your networking configuration. If using DNS to route requests to the appropriate site, then you can, for example, edit your local machine's `/etc/hosts` file to route your requests to the desired secondary site. If the Geo sites are all behind a load balancer, then depending on the load balancer, you might be able to configure all requests from your IP to go to a particular secondary site.

View File

@ -81,8 +81,8 @@ While this isn't an exhaustive list, following these steps gives you a solid sta
- Set password length limit, configure SSO or SAML user management.
- Limit email domains if allowing sign-up.
- Require two-factor authentication (2FA).
- [Disable password authentication](../user/admin_area/settings/sign_in_restrictions.md#password-authentication-enabled) for Git over HTTPS.
- Set up [email notification for unknown sign-ins](../user/admin_area/settings/sign_in_restrictions.md#email-notification-for-unknown-sign-ins).
- [Disable password authentication](settings/sign_in_restrictions.md#password-authentication-enabled) for Git over HTTPS.
- Set up [email notification for unknown sign-ins](settings/sign_in_restrictions.md#email-notification-for-unknown-sign-ins).
- Configure [user and IP rate limits](https://about.gitlab.com/blog/2020/05/20/gitlab-instance-security-best-practices/#user-and-ip-rate-limits).
- Limit [webhooks local access](https://about.gitlab.com/blog/2020/05/20/gitlab-instance-security-best-practices/#webhooks).
- Set [rate limits for protected paths](../user/admin_area/settings/protected_paths.md).

View File

@ -391,9 +391,11 @@ To delete these references:
ls -al /var/opt/gitlab/gitlab-rails/shared/lfs-objects/00/66/22269c61b41bf14a22bbe0e43be3acf86a4a446afb4250c3794ea47541a7
```
1. If the file is not present, remove the database record via the rails console:
1. If the file is not present, remove the database records via the rails console:
```ruby
# First delete the parent records and then destroy the record itself
lfs_object.lfs_objects_projects.destroy_all
lfs_object.destroy
```

View File

@ -11,8 +11,7 @@ the package assumes the defaults as noted below.
## Ports
See the table below for the list of ports that the Omnibus GitLab assigns
by default:
See the table below for the list of ports that the Linux package assigns by default:
| Component | On by default | Communicates via | Alternative | Connection port |
|:--------------------:|:-------------:|:----------------:|:-----------:|:------------------------------------------:|

View File

@ -4,9 +4,9 @@ group: Distribution
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
---
# Omnibus GitLab deprecation policy **(FREE SELF)**
# Linux package deprecation policy **(FREE SELF)**
The Omnibus GitLab packages come with number of different libraries and services which offers users plethora of configuration options.
The Linux packages come with number of different libraries and services which offers users plethora of configuration options.
As libraries and services get updated, their configuration options change
and become obsolete. To increase maintainability and preserve a working
@ -16,7 +16,7 @@ setup, various configuration requires removal.
### Policy
The Omnibus GitLab package retains configuration for at least **one major**
The Linux package retains configuration for at least **one major**
version. We can't guarantee that deprecated configuration
is available in the next major release. See [example](#example) for more details.
@ -49,7 +49,8 @@ Deprecation procedure is similar for both `sensitive` and `regular` configuratio
Common steps:
1. Create an issue at the [Omnibus GitLab issue tracker](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues) with details on deprecation type and other necessary information. Apply the label `deprecation`.
1. Create an issue at the [`omnibus-gitlab` issue tracker](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues) with
details on deprecation type and other necessary information. Apply the label `deprecation`.
1. Decide on the removal target for the deprecated configuration
1. Formulate deprecation notice for each item as noted in [Notice section](#notice)

View File

@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Package information **(FREE SELF)**
The Omnibus GitLab package is bundled with all dependencies required for GitLab
The Linux package is bundled with all dependencies required for GitLab
to function correctly. More details can be found
at [bundling dependencies document](omnibus_packages.md).
@ -14,11 +14,11 @@ at [bundling dependencies document](omnibus_packages.md).
The released package versions are in the format `MAJOR.MINOR.PATCH-EDITION.OMNIBUS_RELEASE`
| Component | Meaning | Example |
|---------------------|---------|---------|
| `MAJOR.MINOR.PATCH` | The GitLab version this corresponds to. | `13.3.0` |
| `EDITION` | The edition of GitLab this corresponds to. | `ee` |
| `OMNIBUS_RELEASE` | The Omnibus GitLab release. Usually, this is 0. This is incremented if we need to build a new package without changing the GitLab version. | `0` |
| Component | Meaning | Example |
|:--------------------|:------------------------------------------------------------------------------------------------------------------------------------------|:---------|
| `MAJOR.MINOR.PATCH` | The GitLab version this corresponds to. | `13.3.0` |
| `EDITION` | The edition of GitLab this corresponds to. | `ee` |
| `OMNIBUS_RELEASE` | The Linux package release. Usually, this is `0`. We increment this if we need to build a new package without changing the GitLab version. | `0` |
## Licenses
@ -26,7 +26,7 @@ See [licensing](licensing.md)
## Defaults
The Omnibus GitLab package requires various configuration to get the components
The Linux package requires various configuration to get the components
in working order. If the configuration is not provided, the package uses
the default values assumed in the package.
@ -34,10 +34,10 @@ These defaults are noted in the package [defaults document](defaults.md).
## Checking the versions of bundled software
After the Omnibus GitLab package is installed, you can find the version of
After the Linux package is installed, you can find the version of
GitLab and all bundled libraries in `/opt/gitlab/version-manifest.txt`.
If you don't have the package installed, you can always check the Omnibus GitLab
If you don't have the package installed, you can always check the Linux package
[source repository](https://gitlab.com/gitlab-org/omnibus-gitlab/tree/master), specifically the
[configuration directory](https://gitlab.com/gitlab-org/omnibus-gitlab/tree/master/config).
@ -51,15 +51,14 @@ Documentation on package signatures can be found at [Signed Packages](signed_pac
## Checking for newer configuration options on upgrade
Configuration file in `/etc/gitlab/gitlab.rb` is created on initial installation
of the Omnibus GitLab package. On subsequent package upgrades, the configuration
file is not updated with new configuration. This is done to avoid
accidental overwrite of user configuration provided in `/etc/gitlab/gitlab.rb`.
The `/etc/gitlab/gitlab.rb` configuration file is created when the Linux package is initially installed.
To avoid accidental overwrites of user configuration, the `/etc/gitlab/gitlab.rb` configuration file is not updated
with new configuration when the Linux package installation is upgraded.
New configuration options are noted in the
[`gitlab.rb.template` file](https://gitlab.com/gitlab-org/omnibus-gitlab/raw/master/files/gitlab-config-template/gitlab.rb.template).
The Omnibus GitLab package also provides convenience command which
The Linux package also provides a convenience command which
compares the existing user configuration with the latest version of the
template contained in the package.
@ -76,7 +75,7 @@ characters on each line.
## Init system detection
Omnibus GitLab attempts to query the underlying system to
The Linux package attempts to query the underlying system to
check which init system it uses.
This manifests itself as a `WARNING` during the `sudo gitlab-ctl reconfigure`
run.

View File

@ -8,12 +8,12 @@ info: To determine the technical writer assigned to the Stage/Group associated w
## License
While GitLab itself is MIT, the Omnibus GitLab sources are licensed under the Apache-2.0.
While GitLab itself is MIT, the Linux package sources are licensed under the Apache-2.0.
## License file location
Starting with version 8.11, the Omnibus GitLab package contains license
information of all software that is bundled within the package.
Starting with version 8.11, the Linux package contains license
information of all software that is bundled in the package.
After installing the package, licenses for each individual bundled library
can be found in `/opt/gitlab/LICENSES` directory.
@ -21,11 +21,11 @@ can be found in `/opt/gitlab/LICENSES` directory.
There is also one `LICENSE` file which contains all licenses compiled together.
This compiled license can be found in `/opt/gitlab/LICENSE` file.
Starting with version 9.2, the Omnibus GitLab package ships a
Starting with version 9.2, the Linux package ships with a
`dependency_licenses.json` file containing version and license information of
all bundled software, including software libraries, Ruby gems that the rails
application uses, and JavaScript libraries that is required for the frontend
components. Because it's in JSON format, GitLab can parse this file easily and use it for automated checks or validations. The file may be found at
components. Because it's in JSON format, GitLab can parse this file and use it for automated checks or validations. The file may be found at
`/opt/gitlab/dependency_licenses.json`.
Starting with version 11.3, we have also made the license information available
@ -33,28 +33,28 @@ online, at: <https://gitlab-org.gitlab.io/omnibus-gitlab/licenses.html>
## Checking licenses
The Omnibus GitLab package is made up of many pieces of software, comprising code
The Linux package is made up of many pieces of software, comprising code
that is covered by many different licenses. Those licenses are provided and
compiled as stated above.
Starting with version 8.13, GitLab has placed an additional step into
Omnibus GitLab. The `license_check` step calls
Linux package installation. The `license_check` step calls
`lib/gitlab/tasks/license_check.rake`, which checks the compiled `LICENSE` file
against the current list of approved and questionable licenses as denoted in the
arrays at the top of the script. This script outputs one of `Good`,
`Unknown` or `Check` for each piece of software that is a part of the
Omnibus GitLab package.
Linux package.
- `Good`: denotes a license that is approved for all usage types, within GitLab and
Omnibus GitLab.
- `Good`: denotes a license that is approved for all usage types, in GitLab and
the Linux package.
- `Unknown`: denotes a license that is not recognized in the list of 'good' or 'bad',
which should be immediately reviewed for implications of use.
- `Check`: denotes a license that has the potential be incompatible with GitLab itself,
and thus should be checked for how it is used as a part of the Omnibus GitLab package
and thus should be checked for how it is used as a part of the Linux package
to ensure compliance.
This list is currently sourced from the [GitLab development documentation on licensing](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/doc/development/licensing.md).
However, due to the nature of the Omnibus GitLab package the licenses may not apply
This list is sourced from the [GitLab development documentation on licensing](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/doc/development/licensing.md).
However, due to the nature of the Linux package, the licenses may not apply
in the same way. Such as with `git` and `rsync`. See the [GNU License FAQ](https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation)
## License acknowledgements

View File

@ -4,7 +4,7 @@ group: Distribution
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
---
# Omnibus based packages and images **(FREE SELF)**
# Packages and images from the Linux package **(FREE SELF)**
Below you can find some basic information on why GitLab provides packages and
a Docker image that come with bundled dependencies.
@ -19,7 +19,7 @@ We have a few core goals with these packages:
1. Support for a wide variety of operating systems
1. Wide support of cloud service providers
## Omnibus GitLab Architecture
## Linux package architecture
GitLab in its core is a Ruby on Rails project. However, GitLab as a whole
application is more complex and has multiple components. If these components are
@ -72,7 +72,7 @@ Some drawbacks of a package with bundled dependencies:
1. Duplication with possibly existing software.
1. Less flexibility in configuration.
## Why would you install an omnibus package when you can use a system package?
## Why would you install a package from the Linux package when you can use a system package?
The answer can be simplified to: less maintenance required. Instead of handling
multiple packages that *can* break existing functionality if the versions are
@ -83,23 +83,24 @@ Keeping configuration in sync can be error prone.
If you have the skill set to maintain all current dependencies and enough time
to handle any future dependencies that might get introduced, the above listed
reasons might not be good enough for you to not use the omnibus package.
reasons might not be good enough for you to not use a package from the Linux package.
There are two things to keep in mind before going down this route:
1. Getting support for any problems
you encounter might be more difficult due to the number of possibilities that exist
when using a library version that is not tested by majority of users.
1. Omnibus package also allows shutting off of any services that you do not need,
1. Packages from the Linux package also allow shutting off of any services that you do not need,
if you need to run a component independently. For example, you can use a
[non-bundled PostgreSQL database](https://docs.gitlab.com/omnibus/settings/database.html#using-a-non-packaged-postgresql-database-management-server) with the omnibus package.
[non-bundled PostgreSQL database](https://docs.gitlab.com/omnibus/settings/database.html#using-a-non-packaged-postgresql-database-management-server)
with a Linux package installation.
Keep in mind that a non-standard solution like the omnibus package
Keep in mind that a non-standard solution like the Linux package
might be a better fit when the application has a number of moving parts.
## Docker image with multiple services
[GitLab Docker image](../../install/docker.md#gitlab-docker-images) is based on the omnibus package.
[GitLab Docker image](../../install/docker.md#gitlab-docker-images) is based on the Linux package.
Considering that container spawned from this image contains multiple processes,
these types of containers are also referred to as 'fat containers'.

View File

@ -4,23 +4,24 @@ group: Distribution
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
---
# PostgreSQL versions shipped with Omnibus GitLab **(FREE SELF)**
# PostgreSQL versions shipped with the Linux package **(FREE SELF)**
NOTE:
This table lists only GitLab versions where a significant change happened in the
package regarding PostgreSQL versions, not all.
Usually, PostgreSQL versions change with major or minor GitLab releases. However, patch versions
of Omnibus GitLab sometimes update the patch level of PostgreSQL. We've established a
of the Linux package sometimes update the patch level of PostgreSQL. We've established a
[yearly cadence for PostgreSQL upgrades](https://about.gitlab.com/handbook/engineering/development/enablement/data_stores/database/postgresql-upgrade-cadence.html)
and trigger automatic database upgrades in the release before the new version is required.
For example:
- Omnibus 12.7.6 shipped with PostgreSQL 9.6.14 and 10.9.
- Omnibus 12.7.7 shipped with PostgreSQL 9.6.17 and 10.12.
- Linux package 12.7.6 shipped with PostgreSQL 9.6.14 and 10.9.
- Linux package 12.7.7 shipped with PostgreSQL 9.6.17 and 10.12.
[Find out which versions of PostgreSQL (and other components) ship with each Omnibus GitLab release](https://gitlab-org.gitlab.io/omnibus-gitlab/licenses.html).
Find out [which versions of PostgreSQL (and other components) ship](https://gitlab-org.gitlab.io/omnibus-gitlab/licenses.html)
with each Linux package release.
The lowest supported PostgreSQL versions are listed in the
[installation requirements](../../install/requirements.md#postgresql-requirements).
@ -37,8 +38,8 @@ Read more about update policies and warnings in the PostgreSQL
| 15.6 | 12.12, 13.8 | 13.8 | 12.12 | For upgrades, users can manually upgrade to 13.8 following the [upgrade documentation](https://docs.gitlab.com/omnibus/settings/database.html#gitlab-150-and-later). |
| 15.0 | 12.10, 13.6 | 13.6 | 12.10 | For upgrades, users can manually upgrade to 13.6 following the [upgrade documentation](https://docs.gitlab.com/omnibus/settings/database.html#gitlab-150-and-later). |
| 14.1 | 12.7, 13.3 | 12.7 | 12.7 | PostgreSQL 13 available for fresh installations if not using [Geo](../geo/index.md#requirements-for-running-geo) or [Patroni](../postgresql/index.md#postgresql-replication-and-failover-with-omnibus-gitlab).
| 14.0 | 12.7 | 12.7 | 12.7 | HA installations with repmgr are no longer supported and are prevented from upgrading to Omnibus GitLab 14.0 |
| 13.8 | 11.9, 12.4 | 12.4 | 12.4 | Package upgrades automatically performed PostgreSQL upgrade for nodes that are not part of a Geo or HA cluster.). |
| 14.0 | 12.7 | 12.7 | 12.7 | HA installations with repmgr are no longer supported and are prevented from upgrading to Linux package 14.0 |
| 13.8 | 11.9, 12.4 | 12.4 | 12.4 | Package upgrades automatically performed PostgreSQL upgrade for nodes that are not part of a Geo or HA cluster. |
| 13.7 | 11.9, 12.4 | 12.4 | 11.9 | For upgrades users can manually upgrade to 12.4 following the [upgrade documentation](https://docs.gitlab.com/omnibus/settings/database.html#gitlab-133-and-later). |
| 13.4 | 11.9, 12.4 | 11.9 | 11.9 | Package upgrades aborted if users not running PostgreSQL 11 already |
| 13.3 | 11.7, 12.3 | 11.7 | 11.7 | Package upgrades aborted if users not running PostgreSQL 11 already |

View File

@ -6,13 +6,22 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Package Signatures **(FREE SELF)**
Omnibus GitLab packages produced by GitLab are created via the [Omnibus](https://github.com/chef/omnibus) tool, for which GitLab has added DEB signing via `debsigs` in [our own fork](https://gitlab.com/gitlab-org/omnibus). This addition, combined with the existing functionality of RPM signing, allows GitLab to provide signed packages for all supported distributions using DEB or RPM.
Linux packages produced by GitLab are created using [Omnibus](https://github.com/chef/omnibus), for which GitLab
has added DEB signing using `debsigs` in [our own fork](https://gitlab.com/gitlab-org/omnibus).
These packages are produced by the GitLab CI process, as found in the [Omnibus GitLab project](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/.gitlab-ci.yml), prior to their delivery to <https://packages.gitlab.com> to ensure provide assurance that the packages are not altered prior to delivery to our community.
Combined with the existing functionality of RPM signing, this addition allows GitLab to provide signed packages for all
supported distributions using DEB or RPM.
These packages are produced by the GitLab CI process, as found in the
[`omnibus-gitlab` project](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/.gitlab-ci.yml),
prior to their delivery to <https://packages.gitlab.com> to provide assurance that the packages are not altered prior
to delivery to our community.
## GnuPG Public Keys
All packages are signed with [GnuPG](https://www.gnupg.org/), in a method appropriate for their format. The key used to sign these packages can be found on [MIT PGP Public Key Server](https://pgp.mit.edu) at [0x3cfcf9baf27eab47](https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3CFCF9BAF27EAB47)
All packages are signed with [GnuPG](https://www.gnupg.org/), in a method appropriate for their format. The key used to
sign these packages can be found on [MIT PGP Public Key Server](https://pgp.mit.edu) at
[`0x3cfcf9baf27eab47`](https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3CFCF9BAF27EAB47).
## Verifying Signatures

View File

@ -83,7 +83,7 @@ running GitLab on ARM.
## OS Versions that are no longer supported
GitLab provides omnibus packages for operating systems only until their
GitLab provides Linux packages for operating systems only until their
EOL (End-Of-Life). After the EOL date of the OS, GitLab stops releasing
official packages. The list of deprecated operating systems and the final GitLab
release for them can be found below:

View File

@ -16,9 +16,11 @@ Registry, see the [user documentation](../../user/packages/container_registry/in
## Enable the Container Registry
**Omnibus GitLab installations**
The process for enabling the Container Registry depends on the type of installation you use.
If you installed GitLab by using the Omnibus installation package, the Container Registry
### Linux package installations
If you installed GitLab by using the Linux package, the Container Registry
may or may not be available by default.
The Container Registry is automatically enabled and available on your GitLab domain, port 5050 if
@ -34,9 +36,9 @@ but it's not recommended and is beyond the scope of this document.
Read the [insecure Registry documentation](https://docs.docker.com/registry/insecure/)
if you want to implement this.
**Installations from source**
### Self-compiled installations
If you have installed GitLab from source:
If you self-compiled your GitLab installation:
1. You must [deploy a registry](https://docs.docker.com/registry/deploying/) using the image corresponding to the
version of GitLab you are installing
@ -115,8 +117,8 @@ certificate.
If the GitLab domain is `https://gitlab.example.com` and the port to the outside world is `5050`,
to configure the Container Registry:
- Edit `gitlab.rb` if you are using Omnibus GitLab.
- Edit `gitlab.yml` if you installed GitLab from source.
- Edit `gitlab.rb` if you are using a Linux package installation.
- Edit `gitlab.yml` if you are using a self-compiled installation.
Ensure you choose a port different than the one that Registry listens to (`5000` by default),
otherwise conflicts occur.
@ -126,7 +128,9 @@ Host and container firewall rules must be configured to allow traffic in through
under the `registry_external_url` line, rather than the port listed under
`gitlab_rails['registry_port']` (default `5000`).
**Omnibus GitLab installations**
::Tabs
:::TabTitle Linux package (Omnibus)
1. Your `/etc/gitlab/gitlab.rb` should contain the Registry URL as well as the
path to the existing TLS certificate and key used by GitLab:
@ -171,7 +175,7 @@ registry_nginx['redirect_http_to_https'] = true
registry_nginx['listen_port'] = 5678
```
**Installations from source**
:::TabTitle Self-compiled (source)
1. Open `/home/git/gitlab/config/gitlab.yml`, find the `registry` entry and
configure it with the following settings:
@ -186,6 +190,8 @@ registry_nginx['listen_port'] = 5678
1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
1. Make the relevant changes in NGINX as well (domain, port, TLS certificates path).
::EndTabs
Users should now be able to sign in to the Container Registry with their GitLab
credentials using:
@ -202,12 +208,14 @@ domain. For example, `*.gitlab.example.com`, is a wildcard that matches `registr
and is distinct from `*.example.com`.
As well as manually generated SSL certificates (explained here), certificates automatically
generated by Let's Encrypt are also [supported in Omnibus installs](https://docs.gitlab.com/omnibus/settings/ssl/index.html).
generated by Let's Encrypt are also [supported in Linux package installations](https://docs.gitlab.com/omnibus/settings/ssl/index.html).
Let's assume that you want the container Registry to be accessible at
`https://registry.gitlab.example.com`.
**Omnibus GitLab installations**
::Tabs
:::TabTitle Linux package (Omnibus)
1. Place your TLS certificate and key in
`/etc/gitlab/ssl/registry.gitlab.example.com.crt` and
@ -237,7 +245,7 @@ registry_nginx['ssl_certificate'] = "/etc/gitlab/ssl/certificate.pem"
registry_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/certificate.key"
```
**Installations from source**
:::TabTitle Self-compiled (source)
1. Open `/home/git/gitlab/config/gitlab.yml`, find the `registry` entry and
configure it with the following settings:
@ -251,6 +259,8 @@ registry_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/certificate.key"
1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
1. Make the relevant changes in NGINX as well (domain, port, TLS certificates path).
::EndTabs
Users should now be able to sign in to the Container Registry using their GitLab
credentials:
@ -264,7 +274,9 @@ When you disable the Registry by following these steps, you do not
remove any existing Docker images. Docker image removal is handled by the
Registry application itself.
**Omnibus GitLab**
::Tabs
:::TabTitle Linux package (Omnibus)
1. Open `/etc/gitlab/gitlab.rb` and set `registry['enable']` to `false`:
@ -274,7 +286,7 @@ Registry application itself.
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
**Installations from source**
:::TabTitle Self-compiled (source)
1. Open `/home/git/gitlab/config/gitlab.yml`, find the `registry` entry and
set `enabled` to `false`:
@ -286,13 +298,17 @@ Registry application itself.
1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
::EndTabs
## Disable Container Registry for new projects site-wide
If the Container Registry is enabled, then it should be available on all new
projects. To disable this function and let the owners of a project to enable
the Container Registry by themselves, follow the steps below.
**Omnibus GitLab installations**
::Tabs
:::TabTitle Linux package (Omnibus)
1. Edit `/etc/gitlab/gitlab.rb` and add the following line:
@ -302,7 +318,7 @@ the Container Registry by themselves, follow the steps below.
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
**Installations from source**
:::TabTitle Self-compiled (source)
1. Open `/home/git/gitlab/config/gitlab.yml`, find the `default_projects_features`
entry and configure it so that `container_registry` is set to `false`:
@ -320,6 +336,8 @@ the Container Registry by themselves, follow the steps below.
1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
::EndTabs
### Increase token duration
In GitLab, tokens for the Container Registry expire every five minutes.
@ -381,9 +399,11 @@ This path is accessible to:
All GitLab, Registry, and web server users must
have access to this directory.
**Omnibus GitLab installations**
::Tabs
The default location where images are stored in Omnibus, is
:::TabTitle Linux package (Omnibus)
The default location where images are stored in Linux package installations is
`/var/opt/gitlab/gitlab-rails/shared/registry`. To change it:
1. Edit `/etc/gitlab/gitlab.rb`:
@ -394,9 +414,9 @@ The default location where images are stored in Omnibus, is
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
**Installations from source**
:::TabTitle Self-compiled (source)
The default location where images are stored in source installations, is
The default location where images are stored in self-compiled installations is
`/home/git/gitlab/shared/registry`. To change it:
1. Open `/home/git/gitlab/config/gitlab.yml`, find the `registry` entry and
@ -409,6 +429,8 @@ The default location where images are stored in source installations, is
1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
::EndTabs
### Use object storage
If you want to store your images on object storage, you can change the storage
@ -421,9 +443,9 @@ GitLab does not back up Docker images that are not stored on the
file system. Enable backups with your object storage provider if
desired.
**Omnibus GitLab installations**
#### Linux package installations
To configure the `s3` storage driver in Omnibus:
To configure the `s3` storage driver for a Linux package installation:
1. Edit `/etc/gitlab/gitlab.rb`:
@ -493,7 +515,7 @@ To configure the `s3` storage driver in Omnibus:
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
**Installations from source**
#### Self-compiled installations
Configuring the storage driver is done in the registry configuration YAML file created
when you [deployed your Docker registry](https://docs.docker.com/registry/deploying/).
@ -602,7 +624,9 @@ When moving from an existing file system or another object storage provider to A
Configure it by setting [`trimlegacyrootprefix: true`](https://gitlab.com/gitlab-org/container-registry/-/blob/a3f64464c3ec1c5a599c0a2daa99ebcbc0100b9a/docs-gitlab/README.md#azure-storage-driver) in the Azure storage driver section of the registry configuration.
Without this configuration, the Azure storage driver uses `//` instead of `/` as the first section of the root path, rendering the migrated images inaccessible.
**Omnibus GitLab installations**
::Tabs
:::TabTitle Linux package (Omnibus)
```ruby
registry['storage'] = {
@ -616,7 +640,7 @@ registry['storage'] = {
}
```
**Installations from source**
:::TabTitle Self-compiled (source)
```yaml
storage:
@ -628,6 +652,8 @@ storage:
trimlegacyrootprefix: true
```
::EndTabs
By default, Azure Storage Driver uses the `core.windows.net` realm. You can set another value for `realm` in the `azure` section (for example, `core.usgovcloudapi.net` for Azure Government Cloud). For more information, see the [Docker documentation](https://docs.docker.com/registry/storage-drivers/azure/).
### Disable redirect for storage driver
@ -636,7 +662,9 @@ By default, users accessing a registry configured with a remote backend are redi
However, this behavior is undesirable for registries used by internal hosts that usually can't access public servers. To disable redirects and [proxy download](../object_storage.md#proxy-download), set the `disable` flag to true as follows. This makes all traffic always go through the Registry service. This results in improved security (less surface attack as the storage backend is not publicly accessible), but worse performance (all traffic is redirected via the service).
**Omnibus GitLab installations**
::Tabs
:::TabTitle Linux package (Omnibus)
1. Edit `/etc/gitlab/gitlab.rb`:
@ -657,7 +685,7 @@ However, this behavior is undesirable for registries used by internal hosts that
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
**Installations from source**
:::TabTitle Self-compiled (source)
1. Add the `redirect` flag to your registry configuration YAML file:
@ -679,6 +707,8 @@ However, this behavior is undesirable for registries used by internal hosts that
1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
::EndTabs
#### Encrypted S3 buckets
You can use server-side encryption with AWS KMS for S3 buckets that have
@ -689,7 +719,9 @@ encryption keys in every request.
For SSE-S3, you must enable the `encrypt` option in the registry settings. How you do this depends
on how you installed GitLab. Follow the instructions here that match your installation method.
For Omnibus GitLab installations:
::Tabs
:::TabTitle Linux package (Omnibus)
1. Edit `/etc/gitlab/gitlab.rb`:
@ -709,7 +741,7 @@ For Omnibus GitLab installations:
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation)
for the changes to take effect.
For installations from source:
:::TabTitle Self-compiled (source)
1. Edit your registry configuration YAML file:
@ -727,6 +759,8 @@ For installations from source:
1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source)
for the changes to take effect.
::EndTabs
### Storage limitations
There is no storage limitation, which means a user can upload an
@ -739,7 +773,9 @@ The Registry server listens on localhost at port `5000` by default,
which is the address for which the Registry server should accept connections.
In the examples below we set the Registry's port to `5010`.
**Omnibus GitLab**
::Tabs
:::TabTitle Linux package (Omnibus)
1. Open `/etc/gitlab/gitlab.rb` and set `registry['registry_http_addr']`:
@ -749,7 +785,7 @@ In the examples below we set the Registry's port to `5010`.
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
**Installations from source**
:::TabTitle Self-compiled (source)
1. Open the configuration file of your Registry server and edit the
[`http:addr`](https://docs.docker.com/registry/configuration/#http) value:
@ -761,6 +797,8 @@ In the examples below we set the Registry's port to `5010`.
1. Save the file and restart the Registry server.
::EndTabs
## Disable Container Registry per project
If Registry is enabled in your GitLab instance, but you don't need it for your
@ -799,7 +837,7 @@ under the project hierarchy, like
`registry.example.com/group/project/my/image-name:tag`, and only recognizes
`registry.example.com/group/project:tag`.
**Omnibus GitLab**
### Linux package installations
You can use GitLab as an auth endpoint with an external container registry.
@ -832,14 +870,14 @@ You can use GitLab as an auth endpoint with an external container registry.
# Example:
registry['internal_key'] = "---BEGIN RSA PRIVATE KEY---\nMIIEpQIBAA\n"
# Optionally define a custom file for Omnibus GitLab to write the contents
# Optionally define a custom file for a Linux package installation to write the contents
# of registry['internal_key'] to.
gitlab_rails['registry_key_path'] = "/custom/path/to/registry-key.key"
```
Each time reconfigure is executed, the file specified at `registry_key_path`
gets populated with the content specified by `internal_key`. If
no file is specified, Omnibus GitLab defaults it to
no file is specified, Linux package installations default it to
`/var/opt/gitlab/gitlab-rails/etc/gitlab-registry.key` and populates
it.
@ -854,7 +892,7 @@ You can use GitLab as an auth endpoint with an external container registry.
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation)
for the changes to take effect.
**Installations from source**
### Self-compiled installations
1. Open `/home/git/gitlab/config/gitlab.yml`, and edit the configuration settings under `registry`:
@ -885,9 +923,11 @@ Read more about the Container Registry notifications configuration options in th
You can configure multiple endpoints for the Container Registry.
**Omnibus GitLab installations**
::Tabs
To configure a notification endpoint in Omnibus:
:::TabTitle Linux package (Omnibus)
To configure a notification endpoint for a Linux package installation:
1. Edit `/etc/gitlab/gitlab.rb`:
@ -908,7 +948,7 @@ To configure a notification endpoint in Omnibus:
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
**Installations from source**
:::TabTitle Self-compiled (source)
Configuring the notification endpoint is done in your registry configuration YAML file created
when you [deployed your Docker registry](https://docs.docker.com/registry/deploying/).
@ -927,6 +967,8 @@ notifications:
backoff: 1000
```
::EndTabs
## Run the Cleanup policy now
WARNING:
@ -1026,7 +1068,7 @@ The time required to perform garbage collection is proportional to the Container
Prerequisites:
- You must have installed GitLab by using an Omnibus package or the
- You must have installed GitLab by using a Linux package or the
[GitLab Helm chart](https://docs.gitlab.com/charts/charts/registry/#garbage-collection).
### Understanding the content-addressable layers
@ -1189,13 +1231,13 @@ itself on the system so that the `gitlab-ctl` command can bring the registry ser
Also, there's no way to save progress or results during the mark phase of the process. Only once
blobs start being deleted is anything permanent done.
## Configuring GitLab and Registry to run on separate nodes (Omnibus GitLab)
## Configure GitLab and Registry to run on separate nodes (Linux package installations)
By default, package assumes that both services are running on the same node.
To get GitLab and Registry to run on a separate nodes, separate configuration
is necessary for Registry and GitLab.
### Configuring Registry
### Configure Registry
Below you can find configuration options you should set in `/etc/gitlab/gitlab.rb`,
for Registry to run separately from GitLab:
@ -1212,7 +1254,7 @@ for Registry to run separately from GitLab:
- `registry['health_storagedriver_enabled']`, default [set programmatically](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/10-7-stable/files/gitlab-cookbooks/gitlab/libraries/registry.rb#L88). Configure whether health checks on the configured storage driver are enabled.
- `gitlab_rails['registry_issuer']`, [default value](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/10-3-stable/files/gitlab-cookbooks/gitlab/attributes/default.rb#L153). This setting needs to be set the same between Registry and GitLab.
### Configuring GitLab
### Configure GitLab
Below you can find configuration options you should set in `/etc/gitlab/gitlab.rb`,
for GitLab to run separately from Registry:
@ -1412,7 +1454,9 @@ level=error msg="response completed with error" err.code=unknown err.detail="une
To resolve the error specify a `chunksize` value in the Registry configuration.
Start with a value between `25000000` (25 MB) and `50000000` (50 MB).
**For Omnibus installations**
::Tabs
:::TabTitle Linux package (Omnibus)
1. Edit `/etc/gitlab/gitlab.rb`:
@ -1429,7 +1473,7 @@ Start with a value between `25000000` (25 MB) and `50000000` (50 MB).
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
**For installations from source**
:::TabTitle Self-compiled (source)
1. Edit `config/gitlab.yml`:
@ -1444,16 +1488,20 @@ Start with a value between `25000000` (25 MB) and `50000000` (50 MB).
1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
::EndTabs
### Supporting older Docker clients
The Docker container registry shipped with GitLab disables the schema1 manifest
by default. If you are still using older Docker clients (1.9 or older), you may
experience an error pushing images. See
[omnibus-4145](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4145) for more details.
[issue 4145](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4145) for more details.
You can add a configuration option for backwards compatibility.
**For Omnibus installations**
::Tabs
:::TabTitle Linux package (Omnibus)
1. Edit `/etc/gitlab/gitlab.rb`:
@ -1463,7 +1511,7 @@ You can add a configuration option for backwards compatibility.
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
**For installations from source**
:::TabTitle Self-compiled (source)
1. Edit the YAML configuration file you created when you [deployed the registry](https://docs.docker.com/registry/deploying/). Add the following snippet:
@ -1475,6 +1523,8 @@ You can add a configuration option for backwards compatibility.
1. Restart the registry for the changes to take affect.
::EndTabs
### Docker connection error
A Docker connection error can occur when there are special characters in either the group,
@ -1499,7 +1549,9 @@ offloaded to a third party reverse proxy.
This problem was discussed in a [Docker project issue](https://github.com/docker/distribution/issues/970)
and a simple solution would be to enable relative URLs in the Registry.
**For Omnibus installations**
::Tabs
:::TabTitle Linux package (Omnibus)
1. Edit `/etc/gitlab/gitlab.rb`:
@ -1511,7 +1563,7 @@ and a simple solution would be to enable relative URLs in the Registry.
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
**For installations from source**
:::TabTitle Self-compiled (source)
1. Edit the YAML configuration file you created when you [deployed the registry](https://docs.docker.com/registry/deploying/). Add the following snippet:
@ -1522,6 +1574,8 @@ and a simple solution would be to enable relative URLs in the Registry.
1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
::EndTabs
### Enable the Registry debug server
You can use the Container Registry debug server to diagnose problems. The debug endpoint can monitor metrics and health, as well as do profiling.
@ -1579,7 +1633,9 @@ for more information.
The following sections provide additional details about each installation method.
#### Helm chart installations
::Tabs
:::TabTitle Helm chart (Kubernetes)
For Helm chart installations:
@ -1591,9 +1647,9 @@ For Helm chart installations:
No other registry configuration changes are required.
#### Omnibus installations
:::TabTitle Linux package (Omnibus)
For Omnibus installations:
For Linux package installations:
1. Temporarily replace the registry binary that ships with GitLab 13.9+ for one prior to
`v3.0.0-gitlab`. To do so, pull a previous version of the Docker image for the GitLab Container
@ -1606,20 +1662,21 @@ For Omnibus installations:
docker rm $id
```
1. Replace the binary embedded in the Omnibus install, located at
1. Replace the binary embedded in the Linux package installation located at
`/opt/gitlab/embedded/bin/registry`, with `registry-2.13.1-gitlab`. Make sure to start by backing
up the original binary embedded in Omnibus, and restore it after performing the
[image upgrade](#images-upgrade)) steps. You should [stop](https://docs.gitlab.com/omnibus/maintenance/#starting-and-stopping)
up the original binary embedded in the Linux package, and restore it after performing the
[image upgrade](#images-upgrade) steps. You should [stop](https://docs.gitlab.com/omnibus/maintenance/#starting-and-stopping)
the registry service before replacing its binary and start it right after. No registry
configuration changes are required.
#### Source installations
:::TabTitle Self-compiled (source)
For source installations, locate your `registry` binary and temporarily replace it with the one
obtained from `v3.0.0-gitlab`, as explained for [Omnibus installations](#omnibus-installations).
obtained from `v3.0.0-gitlab`, as explained for Linux package installations.
Make sure to start by backing up the original registry binary, and restore it after performing the
[images upgrade](#images-upgrade))
steps.
[images upgrade](#images-upgrade) steps.
::EndTabs
#### Images upgrade

View File

@ -25,13 +25,11 @@ The GitLab Dependency Proxy:
The Dependency Proxy is enabled by default. If you are an administrator, you
can turn off the Dependency Proxy. To turn off the Dependency Proxy, follow the instructions that
correspond to your GitLab installation:
correspond to your GitLab installation.
- [Omnibus GitLab installations](#omnibus-gitlab-installations)
- [Helm chart installations](#helm-chart-installations)
- [Installations from source](#installations-from-source)
::Tabs
### Omnibus GitLab installations
:::TabTitle Linux package (Omnibus)
1. Edit `/etc/gitlab/gitlab.rb` and add the following line:
@ -42,7 +40,7 @@ correspond to your GitLab installation:
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation)
for the changes to take effect.
### Helm chart installations
:::TabTitle Helm chart (Kubernetes)
After the installation is complete, update the global `appConfig` to turn off the Dependency Proxy:
@ -59,7 +57,7 @@ global:
For more information, see [Configure Charts using Globals](https://docs.gitlab.com/charts/charts/globals.html#configure-appconfig-settings).
### Installations from source
:::TabTitle Self-compiled (source)
1. After the installation is complete, configure the `dependency_proxy` section in
`config/gitlab.yml`. Set `enabled` to `false` to turn off the Dependency Proxy:
@ -69,13 +67,13 @@ For more information, see [Configure Charts using Globals](https://docs.gitlab.c
enabled: false
```
1. [Restart GitLab](../restart_gitlab.md#installations-from-source "How to restart GitLab")
for the changes to take effect.
1. [Restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
::EndTabs
### Multi-node GitLab installations
Follow the steps for [Omnibus GitLab installations](#omnibus-gitlab-installations)
for each Web and Sidekiq node.
Follow the steps for Linux package installations for each Web and Sidekiq node.
## Turn on the Dependency Proxy
@ -91,12 +89,13 @@ local location or even use object storage.
### Changing the local storage path
The Dependency Proxy files for Omnibus GitLab installations are stored under
The Dependency Proxy files for Linux package installations are stored under
`/var/opt/gitlab/gitlab-rails/shared/dependency_proxy/` and for source
installations under `shared/dependency_proxy/` (relative to the Git home directory).
To change the local storage path:
**Omnibus GitLab installations**
::Tabs
:::TabTitle Linux package (Omnibus)
1. Edit `/etc/gitlab/gitlab.rb` and add the following line:
@ -106,7 +105,7 @@ To change the local storage path:
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
**Installations from source**
:::TabTitle Self-compiled (source)
1. Edit the `dependency_proxy` section in `config/gitlab.yml`:
@ -116,7 +115,9 @@ To change the local storage path:
storage_path: shared/dependency_proxy
```
1. [Restart GitLab](../restart_gitlab.md#installations-from-source "How to restart GitLab") for the changes to take effect.
1. [Restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
::EndTabs
### Using object storage
@ -127,7 +128,9 @@ This section describes the earlier configuration format. [Migration steps still
[Read more about using object storage with GitLab](../object_storage.md).
**Omnibus GitLab installations**
::Tabs
:::TabTitle Linux package (Omnibus)
1. Edit `/etc/gitlab/gitlab.rb` and add the following lines (uncomment where
necessary):
@ -158,7 +161,7 @@ This section describes the earlier configuration format. [Migration steps still
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
**Installations from source**
:::TabTitle Self-compiled (source)
1. Edit the `dependency_proxy` section in `config/gitlab.yml` (uncomment where necessary):
@ -190,7 +193,9 @@ This section describes the earlier configuration format. [Migration steps still
# path_style: false # If true, use 'host/bucket_name/object' instead of 'bucket_name.host/object'.
```
1. [Restart GitLab](../restart_gitlab.md#installations-from-source "How to restart GitLab") for the changes to take effect.
1. [Restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
::EndTabs
#### Migrate local Dependency Proxy blobs and manifests to object storage
@ -200,24 +205,24 @@ After [configuring object storage](#using-object-storage),
use the following task to migrate existing Dependency Proxy blobs and manifests from local storage
to remote storage. The processing is done in a background worker and requires no downtime.
For Omnibus GitLab:
- For Linux package installations:
```shell
sudo gitlab-rake "gitlab:dependency_proxy:migrate"
```
```shell
sudo gitlab-rake "gitlab:dependency_proxy:migrate"
```
For installations from source:
- For installations from source:
```shell
RAILS_ENV=production sudo -u git -H bundle exec rake gitlab:dependency_proxy:migrate
```
```shell
RAILS_ENV=production sudo -u git -H bundle exec rake gitlab:dependency_proxy:migrate
```
You can optionally track progress and verify that all Dependency Proxy blobs and manifests migrated successfully using the
[PostgreSQL console](https://docs.gitlab.com/omnibus/settings/database.html#connecting-to-the-bundled-postgresql-database):
- `sudo gitlab-rails dbconsole` for Omnibus GitLab 14.1 and earlier.
- `sudo gitlab-rails dbconsole --database main` for Omnibus GitLab 14.2 and later.
- `sudo -u git -H psql -d gitlabhq_production` for source-installed instances.
- `sudo gitlab-rails dbconsole` for Linux package installations running version 14.1 and earlier.
- `sudo gitlab-rails dbconsole --database main` for Linux package installations running version 14.2 and later.
- `sudo -u git -H psql -d gitlabhq_production` for self-compiled instances.
Verify that `objectstg` (where `file_store = '2'`) has the count of all Dependency Proxy blobs and
manifests for each respective query:

View File

@ -0,0 +1,203 @@
---
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
---
# Sign-in restrictions **(FREE SELF)**
You can use **Sign-in restrictions** to customize authentication restrictions for web interfaces as well as Git over HTTP(S).
## Settings
To access sign-in restriction settings:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand the **Sign-in restrictions** section.
## Password authentication enabled
You can restrict the password authentication for web interface and Git over HTTP(S):
- **Web interface**: When this feature is disabled, the **Standard** sign-in tab
is removed and an [external authentication provider](../auth/index.md)
must be used.
- **Git over HTTP(S)**: When this feature is disabled, a [Personal Access Token](../../user/profile/personal_access_tokens.md)
or LDAP password must be used to authenticate.
In the event of an external authentication provider outage, use the [GitLab Rails console](../operations/rails_console.md) to [re-enable the standard web sign-in form](#re-enable-standard-web-sign-in-form-in-rails-console). This configuration can also be changed over the [Application settings REST API](../../api/settings.md#change-application-settings) while authenticating with an administrator account's personal access token.
## Admin Mode
> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2158) in GitLab 13.10.
If you're an administrator, you might want to work in GitLab without administrator access.
You could either create a separate user account that does not have
administrator access or use Admin Mode.
With Admin Mode, your account does not have administrator access by default.
You can continue to access groups and projects you're a member of. However, for administrative tasks,
you must authenticate (except for [certain features](#limitations-of-admin-mode)).
When Admin Mode is enabled, it applies to all administrators on the instance.
When Admin Mode is enabled for an instance, administrators:
- Are allowed to access group and projects for which they are members.
- Cannot access the **Admin Area**.
### Enable Admin Mode for your instance
Administrators can enable Admin Mode though the API, the Rails console, or the UI.
#### Use the API to enable Admin Mode
Make the following request to your instance endpoint:
```shell
curl --request PUT --header "PRIVATE-TOKEN:$ADMIN_TOKEN" "<gitlab.example.com>/api/v4/application/settings?admin_mode=true"
```
Replace `<gitlab.example.com>` with your instance URL.
For more information, see the [list of settings that can be accessed through API calls](../../api/settings.md).
#### Use the Rails console to enable Admin Mode
Open the [Rails console](../operations/rails_console.md) and run the following:
```ruby
::Gitlab::CurrentSettings.update!(admin_mode: true)
```
#### Use the UI to enable Admin Mode
To enable Admin Mode through the UI:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand **Sign-in restrictions**.
1. In the **Admin Mode** section, select the **Require additional authentication for administrative tasks** checkbox.
### Turn on Admin Mode for your session
To turn on Admin Mode for your current session and access potentially dangerous resources:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Enter Admin Mode**.
1. Try to access any part of the UI with `/admin` in the URL (which requires administrator access).
When Admin Mode status is disabled or turned off, administrators cannot access resources unless
they've been explicitly granted access. For example, administrators get a `404` error
if they try to open a private group or project, unless they are members of that group or project.
2FA should be enabled for administrators. 2FA, OmniAuth providers, and LDAP
authentication are supported by Admin Mode. Admin Mode status is stored in the current user session and remains active until either:
- It is explicitly disabled.
- It is disabled automatically after six hours.
### Turn off Admin Mode for your session
To turn off Admin Mode for your current session:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Leave Admin Mode**.
### Limitations of Admin Mode
Admin Mode times out after six hours, and you cannot change this timeout limit.
The following access methods are **not** protected by Admin Mode:
- Git client access (SSH using public keys or HTTPS using Personal Access Tokens).
In other words, administrators who are otherwise limited by Admin Mode can still use
Git clients without additional authentication steps.
To use the GitLab REST- or GraphQL API, administrators must [create a personal access token](../../user/profile/personal_access_tokens.md#create-a-personal-access-token) with the [`admin_mode` scope](../../user/profile/personal_access_tokens.md#personal-access-token-scopes).
If an administrator with a personal access token with the `admin_mode` scope loses their administrator access, that user cannot access the API as an administrator even though they still have the token with the `admin_mode` scope.
We may address these limitations in the future. For more information see the following epic:
[Admin Mode for GitLab Administrators](https://gitlab.com/groups/gitlab-org/-/epics/2158).
Also, when GitLab Geo is enabled, you can't view the replication status of projects and designs while
on a secondary node. A fix is proposed when projects ([issue 367926](https://gitlab.com/gitlab-org/gitlab/-/issues/367926)) and designs ([issue 355660](https://gitlab.com/gitlab-org/gitlab/-/issues/355660)) move to the new Geo framework.
### Troubleshooting Admin Mode
If necessary, you can disable **Admin Mode** as an administrator by using one of these two methods:
- **API**:
```shell
curl --request PUT --header "PRIVATE-TOKEN:$ADMIN_TOKEN" "<gitlab-url>/api/v4/application/settings?admin_mode=false"
```
- [**Rails console**](../operations/rails_console.md#starting-a-rails-console-session):
```ruby
::Gitlab::CurrentSettings.update!(admin_mode: false)
```
## Two-factor authentication
When this feature is enabled, all users must use the [two-factor authentication](../../user/profile/account/two_factor_authentication.md).
After the two-factor authentication is configured as mandatory, users are allowed
to skip forced configuration of two-factor authentication for the configurable grace
period in hours.
![Two-factor grace period](../../user/admin_area/settings/img/two_factor_grace_period.png)
## Email notification for unknown sign-ins
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/218457) in GitLab 13.2.
When enabled, GitLab notifies users of sign-ins from unknown IP addresses or devices. For more information,
see [Email notification for unknown sign-ins](../../user/profile/notifications.md#notifications-for-unknown-sign-ins).
![Email notification for unknown sign-ins](../../user/admin_area/settings/img/email_notification_for_unknown_sign_ins_v13_2.png)
## Sign-in information
All users that are not logged in are redirected to the page represented by the configured
**Home page URL** if value is not empty.
All users are redirected to the page represented by the configured **Sign-out page URL**
after sign out if value is not empty.
In the **Sign-in restrictions** section, scroll to the **Sign-in text** field. You can add a
custom message for your users in Markdown format.
For example, if you include the following information in the noted text box:
```markdown
# Custom sign-in text
To access this text box:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand the **Sign-in restrictions** section.
```
Your users see the **Custom sign-in text** when they navigate to the sign-in screen for your
GitLab instance.
## Troubleshooting
### Re-enable standard web sign-in form in rails console
Re-enable the standard username and password-based sign-in form if it was disabled as a [Sign-in restriction](#password-authentication-enabled).
You can use this method through the [rails console](../operations/rails_console.md#starting-a-rails-console-session) when a configured external authentication provider (through SSO or an LDAP configuration) is facing an outage and direct sign-in access to GitLab is required.
```ruby
Gitlab::CurrentSettings.update!(password_authentication_enabled_for_web: true)
```

View File

@ -17903,6 +17903,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
| <a id="mergerequestassigneeassignedmergerequestscreatedafter"></a>`createdAfter` | [`Time`](#time) | Merge requests created after this timestamp. |
| <a id="mergerequestassigneeassignedmergerequestscreatedbefore"></a>`createdBefore` | [`Time`](#time) | Merge requests created before this timestamp. |
| <a id="mergerequestassigneeassignedmergerequestsdraft"></a>`draft` | [`Boolean`](#boolean) | Limit result to draft merge requests. |
| <a id="mergerequestassigneeassignedmergerequestsgroupid"></a>`groupId` | [`GroupID`](#groupid) | The global ID of the group the authored merge requests should be in. Merge requests in subgroups are included. |
| <a id="mergerequestassigneeassignedmergerequestsiids"></a>`iids` | [`[String!]`](#string) | Array of IIDs of merge requests, for example `[1, 2]`. |
| <a id="mergerequestassigneeassignedmergerequestslabels"></a>`labels` | [`[String!]`](#string) | Array of label names. All resolved merge requests will have all of these labels. |
| <a id="mergerequestassigneeassignedmergerequestsmergedafter"></a>`mergedAfter` | [`Time`](#time) | Merge requests merged after this date. |
@ -17938,6 +17939,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
| <a id="mergerequestassigneeauthoredmergerequestscreatedafter"></a>`createdAfter` | [`Time`](#time) | Merge requests created after this timestamp. |
| <a id="mergerequestassigneeauthoredmergerequestscreatedbefore"></a>`createdBefore` | [`Time`](#time) | Merge requests created before this timestamp. |
| <a id="mergerequestassigneeauthoredmergerequestsdraft"></a>`draft` | [`Boolean`](#boolean) | Limit result to draft merge requests. |
| <a id="mergerequestassigneeauthoredmergerequestsgroupid"></a>`groupId` | [`GroupID`](#groupid) | The global ID of the group the authored merge requests should be in. Merge requests in subgroups are included. |
| <a id="mergerequestassigneeauthoredmergerequestsiids"></a>`iids` | [`[String!]`](#string) | Array of IIDs of merge requests, for example `[1, 2]`. |
| <a id="mergerequestassigneeauthoredmergerequestslabels"></a>`labels` | [`[String!]`](#string) | Array of label names. All resolved merge requests will have all of these labels. |
| <a id="mergerequestassigneeauthoredmergerequestsmergedafter"></a>`mergedAfter` | [`Time`](#time) | Merge requests merged after this date. |
@ -17991,6 +17993,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
| <a id="mergerequestassigneereviewrequestedmergerequestscreatedafter"></a>`createdAfter` | [`Time`](#time) | Merge requests created after this timestamp. |
| <a id="mergerequestassigneereviewrequestedmergerequestscreatedbefore"></a>`createdBefore` | [`Time`](#time) | Merge requests created before this timestamp. |
| <a id="mergerequestassigneereviewrequestedmergerequestsdraft"></a>`draft` | [`Boolean`](#boolean) | Limit result to draft merge requests. |
| <a id="mergerequestassigneereviewrequestedmergerequestsgroupid"></a>`groupId` | [`GroupID`](#groupid) | The global ID of the group the authored merge requests should be in. Merge requests in subgroups are included. |
| <a id="mergerequestassigneereviewrequestedmergerequestsiids"></a>`iids` | [`[String!]`](#string) | Array of IIDs of merge requests, for example `[1, 2]`. |
| <a id="mergerequestassigneereviewrequestedmergerequestslabels"></a>`labels` | [`[String!]`](#string) | Array of label names. All resolved merge requests will have all of these labels. |
| <a id="mergerequestassigneereviewrequestedmergerequestsmergedafter"></a>`mergedAfter` | [`Time`](#time) | Merge requests merged after this date. |
@ -18179,6 +18182,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
| <a id="mergerequestauthorassignedmergerequestscreatedafter"></a>`createdAfter` | [`Time`](#time) | Merge requests created after this timestamp. |
| <a id="mergerequestauthorassignedmergerequestscreatedbefore"></a>`createdBefore` | [`Time`](#time) | Merge requests created before this timestamp. |
| <a id="mergerequestauthorassignedmergerequestsdraft"></a>`draft` | [`Boolean`](#boolean) | Limit result to draft merge requests. |
| <a id="mergerequestauthorassignedmergerequestsgroupid"></a>`groupId` | [`GroupID`](#groupid) | The global ID of the group the authored merge requests should be in. Merge requests in subgroups are included. |
| <a id="mergerequestauthorassignedmergerequestsiids"></a>`iids` | [`[String!]`](#string) | Array of IIDs of merge requests, for example `[1, 2]`. |
| <a id="mergerequestauthorassignedmergerequestslabels"></a>`labels` | [`[String!]`](#string) | Array of label names. All resolved merge requests will have all of these labels. |
| <a id="mergerequestauthorassignedmergerequestsmergedafter"></a>`mergedAfter` | [`Time`](#time) | Merge requests merged after this date. |
@ -18214,6 +18218,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
| <a id="mergerequestauthorauthoredmergerequestscreatedafter"></a>`createdAfter` | [`Time`](#time) | Merge requests created after this timestamp. |
| <a id="mergerequestauthorauthoredmergerequestscreatedbefore"></a>`createdBefore` | [`Time`](#time) | Merge requests created before this timestamp. |
| <a id="mergerequestauthorauthoredmergerequestsdraft"></a>`draft` | [`Boolean`](#boolean) | Limit result to draft merge requests. |
| <a id="mergerequestauthorauthoredmergerequestsgroupid"></a>`groupId` | [`GroupID`](#groupid) | The global ID of the group the authored merge requests should be in. Merge requests in subgroups are included. |
| <a id="mergerequestauthorauthoredmergerequestsiids"></a>`iids` | [`[String!]`](#string) | Array of IIDs of merge requests, for example `[1, 2]`. |
| <a id="mergerequestauthorauthoredmergerequestslabels"></a>`labels` | [`[String!]`](#string) | Array of label names. All resolved merge requests will have all of these labels. |
| <a id="mergerequestauthorauthoredmergerequestsmergedafter"></a>`mergedAfter` | [`Time`](#time) | Merge requests merged after this date. |
@ -18267,6 +18272,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
| <a id="mergerequestauthorreviewrequestedmergerequestscreatedafter"></a>`createdAfter` | [`Time`](#time) | Merge requests created after this timestamp. |
| <a id="mergerequestauthorreviewrequestedmergerequestscreatedbefore"></a>`createdBefore` | [`Time`](#time) | Merge requests created before this timestamp. |
| <a id="mergerequestauthorreviewrequestedmergerequestsdraft"></a>`draft` | [`Boolean`](#boolean) | Limit result to draft merge requests. |
| <a id="mergerequestauthorreviewrequestedmergerequestsgroupid"></a>`groupId` | [`GroupID`](#groupid) | The global ID of the group the authored merge requests should be in. Merge requests in subgroups are included. |
| <a id="mergerequestauthorreviewrequestedmergerequestsiids"></a>`iids` | [`[String!]`](#string) | Array of IIDs of merge requests, for example `[1, 2]`. |
| <a id="mergerequestauthorreviewrequestedmergerequestslabels"></a>`labels` | [`[String!]`](#string) | Array of label names. All resolved merge requests will have all of these labels. |
| <a id="mergerequestauthorreviewrequestedmergerequestsmergedafter"></a>`mergedAfter` | [`Time`](#time) | Merge requests merged after this date. |
@ -18502,6 +18508,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
| <a id="mergerequestparticipantassignedmergerequestscreatedafter"></a>`createdAfter` | [`Time`](#time) | Merge requests created after this timestamp. |
| <a id="mergerequestparticipantassignedmergerequestscreatedbefore"></a>`createdBefore` | [`Time`](#time) | Merge requests created before this timestamp. |
| <a id="mergerequestparticipantassignedmergerequestsdraft"></a>`draft` | [`Boolean`](#boolean) | Limit result to draft merge requests. |
| <a id="mergerequestparticipantassignedmergerequestsgroupid"></a>`groupId` | [`GroupID`](#groupid) | The global ID of the group the authored merge requests should be in. Merge requests in subgroups are included. |
| <a id="mergerequestparticipantassignedmergerequestsiids"></a>`iids` | [`[String!]`](#string) | Array of IIDs of merge requests, for example `[1, 2]`. |
| <a id="mergerequestparticipantassignedmergerequestslabels"></a>`labels` | [`[String!]`](#string) | Array of label names. All resolved merge requests will have all of these labels. |
| <a id="mergerequestparticipantassignedmergerequestsmergedafter"></a>`mergedAfter` | [`Time`](#time) | Merge requests merged after this date. |
@ -18537,6 +18544,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
| <a id="mergerequestparticipantauthoredmergerequestscreatedafter"></a>`createdAfter` | [`Time`](#time) | Merge requests created after this timestamp. |
| <a id="mergerequestparticipantauthoredmergerequestscreatedbefore"></a>`createdBefore` | [`Time`](#time) | Merge requests created before this timestamp. |
| <a id="mergerequestparticipantauthoredmergerequestsdraft"></a>`draft` | [`Boolean`](#boolean) | Limit result to draft merge requests. |
| <a id="mergerequestparticipantauthoredmergerequestsgroupid"></a>`groupId` | [`GroupID`](#groupid) | The global ID of the group the authored merge requests should be in. Merge requests in subgroups are included. |
| <a id="mergerequestparticipantauthoredmergerequestsiids"></a>`iids` | [`[String!]`](#string) | Array of IIDs of merge requests, for example `[1, 2]`. |
| <a id="mergerequestparticipantauthoredmergerequestslabels"></a>`labels` | [`[String!]`](#string) | Array of label names. All resolved merge requests will have all of these labels. |
| <a id="mergerequestparticipantauthoredmergerequestsmergedafter"></a>`mergedAfter` | [`Time`](#time) | Merge requests merged after this date. |
@ -18590,6 +18598,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
| <a id="mergerequestparticipantreviewrequestedmergerequestscreatedafter"></a>`createdAfter` | [`Time`](#time) | Merge requests created after this timestamp. |
| <a id="mergerequestparticipantreviewrequestedmergerequestscreatedbefore"></a>`createdBefore` | [`Time`](#time) | Merge requests created before this timestamp. |
| <a id="mergerequestparticipantreviewrequestedmergerequestsdraft"></a>`draft` | [`Boolean`](#boolean) | Limit result to draft merge requests. |
| <a id="mergerequestparticipantreviewrequestedmergerequestsgroupid"></a>`groupId` | [`GroupID`](#groupid) | The global ID of the group the authored merge requests should be in. Merge requests in subgroups are included. |
| <a id="mergerequestparticipantreviewrequestedmergerequestsiids"></a>`iids` | [`[String!]`](#string) | Array of IIDs of merge requests, for example `[1, 2]`. |
| <a id="mergerequestparticipantreviewrequestedmergerequestslabels"></a>`labels` | [`[String!]`](#string) | Array of label names. All resolved merge requests will have all of these labels. |
| <a id="mergerequestparticipantreviewrequestedmergerequestsmergedafter"></a>`mergedAfter` | [`Time`](#time) | Merge requests merged after this date. |
@ -18813,6 +18822,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
| <a id="mergerequestreviewerassignedmergerequestscreatedafter"></a>`createdAfter` | [`Time`](#time) | Merge requests created after this timestamp. |
| <a id="mergerequestreviewerassignedmergerequestscreatedbefore"></a>`createdBefore` | [`Time`](#time) | Merge requests created before this timestamp. |
| <a id="mergerequestreviewerassignedmergerequestsdraft"></a>`draft` | [`Boolean`](#boolean) | Limit result to draft merge requests. |
| <a id="mergerequestreviewerassignedmergerequestsgroupid"></a>`groupId` | [`GroupID`](#groupid) | The global ID of the group the authored merge requests should be in. Merge requests in subgroups are included. |
| <a id="mergerequestreviewerassignedmergerequestsiids"></a>`iids` | [`[String!]`](#string) | Array of IIDs of merge requests, for example `[1, 2]`. |
| <a id="mergerequestreviewerassignedmergerequestslabels"></a>`labels` | [`[String!]`](#string) | Array of label names. All resolved merge requests will have all of these labels. |
| <a id="mergerequestreviewerassignedmergerequestsmergedafter"></a>`mergedAfter` | [`Time`](#time) | Merge requests merged after this date. |
@ -18848,6 +18858,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
| <a id="mergerequestreviewerauthoredmergerequestscreatedafter"></a>`createdAfter` | [`Time`](#time) | Merge requests created after this timestamp. |
| <a id="mergerequestreviewerauthoredmergerequestscreatedbefore"></a>`createdBefore` | [`Time`](#time) | Merge requests created before this timestamp. |
| <a id="mergerequestreviewerauthoredmergerequestsdraft"></a>`draft` | [`Boolean`](#boolean) | Limit result to draft merge requests. |
| <a id="mergerequestreviewerauthoredmergerequestsgroupid"></a>`groupId` | [`GroupID`](#groupid) | The global ID of the group the authored merge requests should be in. Merge requests in subgroups are included. |
| <a id="mergerequestreviewerauthoredmergerequestsiids"></a>`iids` | [`[String!]`](#string) | Array of IIDs of merge requests, for example `[1, 2]`. |
| <a id="mergerequestreviewerauthoredmergerequestslabels"></a>`labels` | [`[String!]`](#string) | Array of label names. All resolved merge requests will have all of these labels. |
| <a id="mergerequestreviewerauthoredmergerequestsmergedafter"></a>`mergedAfter` | [`Time`](#time) | Merge requests merged after this date. |
@ -18901,6 +18912,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
| <a id="mergerequestreviewerreviewrequestedmergerequestscreatedafter"></a>`createdAfter` | [`Time`](#time) | Merge requests created after this timestamp. |
| <a id="mergerequestreviewerreviewrequestedmergerequestscreatedbefore"></a>`createdBefore` | [`Time`](#time) | Merge requests created before this timestamp. |
| <a id="mergerequestreviewerreviewrequestedmergerequestsdraft"></a>`draft` | [`Boolean`](#boolean) | Limit result to draft merge requests. |
| <a id="mergerequestreviewerreviewrequestedmergerequestsgroupid"></a>`groupId` | [`GroupID`](#groupid) | The global ID of the group the authored merge requests should be in. Merge requests in subgroups are included. |
| <a id="mergerequestreviewerreviewrequestedmergerequestsiids"></a>`iids` | [`[String!]`](#string) | Array of IIDs of merge requests, for example `[1, 2]`. |
| <a id="mergerequestreviewerreviewrequestedmergerequestslabels"></a>`labels` | [`[String!]`](#string) | Array of label names. All resolved merge requests will have all of these labels. |
| <a id="mergerequestreviewerreviewrequestedmergerequestsmergedafter"></a>`mergedAfter` | [`Time`](#time) | Merge requests merged after this date. |
@ -23386,6 +23398,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
| <a id="usercoreassignedmergerequestscreatedafter"></a>`createdAfter` | [`Time`](#time) | Merge requests created after this timestamp. |
| <a id="usercoreassignedmergerequestscreatedbefore"></a>`createdBefore` | [`Time`](#time) | Merge requests created before this timestamp. |
| <a id="usercoreassignedmergerequestsdraft"></a>`draft` | [`Boolean`](#boolean) | Limit result to draft merge requests. |
| <a id="usercoreassignedmergerequestsgroupid"></a>`groupId` | [`GroupID`](#groupid) | The global ID of the group the authored merge requests should be in. Merge requests in subgroups are included. |
| <a id="usercoreassignedmergerequestsiids"></a>`iids` | [`[String!]`](#string) | Array of IIDs of merge requests, for example `[1, 2]`. |
| <a id="usercoreassignedmergerequestslabels"></a>`labels` | [`[String!]`](#string) | Array of label names. All resolved merge requests will have all of these labels. |
| <a id="usercoreassignedmergerequestsmergedafter"></a>`mergedAfter` | [`Time`](#time) | Merge requests merged after this date. |
@ -23421,6 +23434,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
| <a id="usercoreauthoredmergerequestscreatedafter"></a>`createdAfter` | [`Time`](#time) | Merge requests created after this timestamp. |
| <a id="usercoreauthoredmergerequestscreatedbefore"></a>`createdBefore` | [`Time`](#time) | Merge requests created before this timestamp. |
| <a id="usercoreauthoredmergerequestsdraft"></a>`draft` | [`Boolean`](#boolean) | Limit result to draft merge requests. |
| <a id="usercoreauthoredmergerequestsgroupid"></a>`groupId` | [`GroupID`](#groupid) | The global ID of the group the authored merge requests should be in. Merge requests in subgroups are included. |
| <a id="usercoreauthoredmergerequestsiids"></a>`iids` | [`[String!]`](#string) | Array of IIDs of merge requests, for example `[1, 2]`. |
| <a id="usercoreauthoredmergerequestslabels"></a>`labels` | [`[String!]`](#string) | Array of label names. All resolved merge requests will have all of these labels. |
| <a id="usercoreauthoredmergerequestsmergedafter"></a>`mergedAfter` | [`Time`](#time) | Merge requests merged after this date. |
@ -23474,6 +23488,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
| <a id="usercorereviewrequestedmergerequestscreatedafter"></a>`createdAfter` | [`Time`](#time) | Merge requests created after this timestamp. |
| <a id="usercorereviewrequestedmergerequestscreatedbefore"></a>`createdBefore` | [`Time`](#time) | Merge requests created before this timestamp. |
| <a id="usercorereviewrequestedmergerequestsdraft"></a>`draft` | [`Boolean`](#boolean) | Limit result to draft merge requests. |
| <a id="usercorereviewrequestedmergerequestsgroupid"></a>`groupId` | [`GroupID`](#groupid) | The global ID of the group the authored merge requests should be in. Merge requests in subgroups are included. |
| <a id="usercorereviewrequestedmergerequestsiids"></a>`iids` | [`[String!]`](#string) | Array of IIDs of merge requests, for example `[1, 2]`. |
| <a id="usercorereviewrequestedmergerequestslabels"></a>`labels` | [`[String!]`](#string) | Array of label names. All resolved merge requests will have all of these labels. |
| <a id="usercorereviewrequestedmergerequestsmergedafter"></a>`mergedAfter` | [`Time`](#time) | Merge requests merged after this date. |
@ -28433,6 +28448,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
| <a id="userassignedmergerequestscreatedafter"></a>`createdAfter` | [`Time`](#time) | Merge requests created after this timestamp. |
| <a id="userassignedmergerequestscreatedbefore"></a>`createdBefore` | [`Time`](#time) | Merge requests created before this timestamp. |
| <a id="userassignedmergerequestsdraft"></a>`draft` | [`Boolean`](#boolean) | Limit result to draft merge requests. |
| <a id="userassignedmergerequestsgroupid"></a>`groupId` | [`GroupID`](#groupid) | The global ID of the group the authored merge requests should be in. Merge requests in subgroups are included. |
| <a id="userassignedmergerequestsiids"></a>`iids` | [`[String!]`](#string) | Array of IIDs of merge requests, for example `[1, 2]`. |
| <a id="userassignedmergerequestslabels"></a>`labels` | [`[String!]`](#string) | Array of label names. All resolved merge requests will have all of these labels. |
| <a id="userassignedmergerequestsmergedafter"></a>`mergedAfter` | [`Time`](#time) | Merge requests merged after this date. |
@ -28468,6 +28484,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
| <a id="userauthoredmergerequestscreatedafter"></a>`createdAfter` | [`Time`](#time) | Merge requests created after this timestamp. |
| <a id="userauthoredmergerequestscreatedbefore"></a>`createdBefore` | [`Time`](#time) | Merge requests created before this timestamp. |
| <a id="userauthoredmergerequestsdraft"></a>`draft` | [`Boolean`](#boolean) | Limit result to draft merge requests. |
| <a id="userauthoredmergerequestsgroupid"></a>`groupId` | [`GroupID`](#groupid) | The global ID of the group the authored merge requests should be in. Merge requests in subgroups are included. |
| <a id="userauthoredmergerequestsiids"></a>`iids` | [`[String!]`](#string) | Array of IIDs of merge requests, for example `[1, 2]`. |
| <a id="userauthoredmergerequestslabels"></a>`labels` | [`[String!]`](#string) | Array of label names. All resolved merge requests will have all of these labels. |
| <a id="userauthoredmergerequestsmergedafter"></a>`mergedAfter` | [`Time`](#time) | Merge requests merged after this date. |
@ -28521,6 +28538,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
| <a id="userreviewrequestedmergerequestscreatedafter"></a>`createdAfter` | [`Time`](#time) | Merge requests created after this timestamp. |
| <a id="userreviewrequestedmergerequestscreatedbefore"></a>`createdBefore` | [`Time`](#time) | Merge requests created before this timestamp. |
| <a id="userreviewrequestedmergerequestsdraft"></a>`draft` | [`Boolean`](#boolean) | Limit result to draft merge requests. |
| <a id="userreviewrequestedmergerequestsgroupid"></a>`groupId` | [`GroupID`](#groupid) | The global ID of the group the authored merge requests should be in. Merge requests in subgroups are included. |
| <a id="userreviewrequestedmergerequestsiids"></a>`iids` | [`[String!]`](#string) | Array of IIDs of merge requests, for example `[1, 2]`. |
| <a id="userreviewrequestedmergerequestslabels"></a>`labels` | [`[String!]`](#string) | Array of label names. All resolved merge requests will have all of these labels. |
| <a id="userreviewrequestedmergerequestsmergedafter"></a>`mergedAfter` | [`Time`](#time) | Merge requests merged after this date. |

View File

@ -10,7 +10,7 @@ The Jira issue integration connects one or more GitLab projects to a Jira instan
## Configure the integration
> Authentication with Jira personal access tokens was [introduced](https://gitlab.com/groups/gitlab-org/-/epics/8222) in GitLab 16.0.
> Authentication with Jira personal access tokens [introduced](https://gitlab.com/groups/gitlab-org/-/epics/8222) in GitLab 16.0.
Prerequisites:

View File

@ -46,8 +46,8 @@ For an overview, see
After you add a group, the following data is synced to Jira for all projects in that group:
- New merge requests, branches, and commits.
- Existing merge requests (GitLab 13.8 and later).
- New and existing merge requests.
- New branches and commits.
- Existing branches and commits (GitLab 15.11 and later). You must delete and add any namespaces that were added to the GitLab for Jira Cloud app in GitLab 15.10 and earlier.
## Update the GitLab for Jira Cloud app

View File

@ -6,8 +6,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Jira development panel **(FREE)**
> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/233149) from GitLab Premium to GitLab Free in 13.4.
You can use the Jira development panel to view GitLab activity for a Jira issue directly in Jira.
To set up the Jira development panel:

View File

@ -49,9 +49,6 @@ You can [disable comments](#disable-comments-on-jira-issues) on issues.
### Require associated Jira issue for merge requests to be merged **(ULTIMATE)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/280766) in GitLab 13.12 [with a flag](../../administration/feature_flags.md) named `jira_issue_association_on_merge_request`. Disabled by default.
> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/335280) in GitLab 14.2. Feature flag `jira_issue_association_on_merge_request` removed.
With this integration, you can prevent merge requests from being merged if they do not refer to a Jira issue.
To enable this feature:
@ -134,8 +131,6 @@ Consider this example:
## View Jira issues **(PREMIUM)**
> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3622) in GitLab 13.2.
You can view and search issues from a selected Jira project directly in GitLab,
provided your GitLab administrator [has configured the integration](configure.md#configure-the-integration).
@ -148,7 +143,7 @@ The issues are sorted by **Created date** by default, with the most recently cre
- To display the most recently updated issues first, select **Updated date**.
- You can [search and filter the issue list](#search-and-filter-the-issue-list).
- In GitLab 13.10 and later, you can [select an issue from the list to view the issue in GitLab](https://gitlab.com/gitlab-org/gitlab/-/issues/299832).
- You can [select an issue from the list to view the issue in GitLab](https://gitlab.com/gitlab-org/gitlab/-/issues/299832).
Issues are grouped into tabs based on their
[Jira status](https://confluence.atlassian.com/adminjiraserver070/defining-status-field-values-749382903.html):
@ -178,8 +173,6 @@ Enhancements to use these filters through the user interface
## Automatic issue transitions
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/55773) in GitLab 13.11.
When you configure automatic issue transitions, you can transition a referenced
Jira issue to the next available status with a category of **Done**. To configure
this setting:

View File

@ -222,9 +222,9 @@ When you close an incident that is linked to an [alert](alerts.md),
the linked alert's status changes to **Resolved**.
You are then credited with the alert's status change.
<!-- Delete when the `moved_mr_sidebar` feature flag is removed -->
<!-- Delete when the `move_close_into_dropdown` feature flag is removed -->
If you don't see this action at the top of an incident, your project or instance might have
enabled a feature flag for [moved actions](../../user/project/merge_requests/index.md#move-sidebar-actions)
enabled a feature flag to [moved it in the actions menu](../../user/project/issues/managing_issues.md#move-the-close-button-into-the-actions-menu).
### Automatically close incidents via recovery alerts

View File

@ -1,203 +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/settings/sign_in_restrictions.md'
remove_date: '2023-10-13'
---
# Sign-in restrictions **(FREE SELF)**
This document was moved to [another location](../../../administration/settings/sign_in_restrictions.md).
You can use **Sign-in restrictions** to customize authentication restrictions for web interfaces as well as Git over HTTP(S).
## Settings
To access sign-in restriction settings:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand the **Sign-in restrictions** section.
## Password authentication enabled
You can restrict the password authentication for web interface and Git over HTTP(S):
- **Web interface**: When this feature is disabled, the **Standard** sign-in tab
is removed and an [external authentication provider](../../../administration/auth/index.md)
must be used.
- **Git over HTTP(S)**: When this feature is disabled, a [Personal Access Token](../../profile/personal_access_tokens.md)
or LDAP password must be used to authenticate.
In the event of an external authentication provider outage, use the [GitLab Rails console](../../../administration/operations/rails_console.md) to [re-enable the standard web sign-in form](#re-enable-standard-web-sign-in-form-in-rails-console). This configuration can also be changed over the [Application settings REST API](../../../api/settings.md#change-application-settings) while authenticating with an administrator account's personal access token.
## Admin Mode
> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2158) in GitLab 13.10.
If you're an administrator, you might want to work in GitLab without administrator access.
You could either create a separate user account that does not have
administrator access or use Admin Mode.
With Admin Mode, your account does not have administrator access by default.
You can continue to access groups and projects you're a member of. However, for administrative tasks,
you must authenticate (except for [certain features](#limitations-of-admin-mode)).
When Admin Mode is enabled, it applies to all administrators on the instance.
When Admin Mode is enabled for an instance, administrators:
- Are allowed to access group and projects for which they are members.
- Cannot access the **Admin Area**.
### Enable Admin Mode for your instance
Administrators can enable Admin Mode though the API, the Rails console, or the UI.
#### Use the API to enable Admin Mode
Make the following request to your instance endpoint:
```shell
curl --request PUT --header "PRIVATE-TOKEN:$ADMIN_TOKEN" "<gitlab.example.com>/api/v4/application/settings?admin_mode=true"
```
Replace `<gitlab.example.com>` with your instance URL.
For more information, see the [list of settings that can be accessed through API calls](../../../api/settings.md).
#### Use the Rails console to enable Admin Mode
Open the [Rails console](../../../administration/operations/rails_console.md) and run the following:
```ruby
::Gitlab::CurrentSettings.update!(admin_mode: true)
```
#### Use the UI to enable Admin Mode
To enable Admin Mode through the UI:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand **Sign-in restrictions**.
1. In the **Admin Mode** section, select the **Require additional authentication for administrative tasks** checkbox.
### Turn on Admin Mode for your session
To turn on Admin Mode for your current session and access potentially dangerous resources:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Enter Admin Mode**.
1. Try to access any part of the UI with `/admin` in the URL (which requires administrator access).
When Admin Mode status is disabled or turned off, administrators cannot access resources unless
they've been explicitly granted access. For example, administrators get a `404` error
if they try to open a private group or project, unless they are members of that group or project.
2FA should be enabled for administrators. 2FA, OmniAuth providers, and LDAP
authentication are supported by Admin Mode. Admin Mode status is stored in the current user session and remains active until either:
- It is explicitly disabled.
- It is disabled automatically after six hours.
### Turn off Admin Mode for your session
To turn off Admin Mode for your current session:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Leave Admin Mode**.
### Limitations of Admin Mode
Admin Mode times out after six hours, and you cannot change this timeout limit.
The following access methods are **not** protected by Admin Mode:
- Git client access (SSH using public keys or HTTPS using Personal Access Tokens).
In other words, administrators who are otherwise limited by Admin Mode can still use
Git clients without additional authentication steps.
To use the GitLab REST- or GraphQL API, administrators must [create a personal access token](../../profile/personal_access_tokens.md#create-a-personal-access-token) with the [`admin_mode` scope](../../profile/personal_access_tokens.md#personal-access-token-scopes).
If an administrator with a personal access token with the `admin_mode` scope loses their administrator access, that user cannot access the API as an administrator even though they still have the token with the `admin_mode` scope.
We may address these limitations in the future. For more information see the following epic:
[Admin Mode for GitLab Administrators](https://gitlab.com/groups/gitlab-org/-/epics/2158).
Also, when GitLab Geo is enabled, you can't view the replication status of projects and designs while
on a secondary node. A fix is proposed when projects ([issue 367926](https://gitlab.com/gitlab-org/gitlab/-/issues/367926)) and designs ([issue 355660](https://gitlab.com/gitlab-org/gitlab/-/issues/355660)) move to the new Geo framework.
### Troubleshooting Admin Mode
If necessary, you can disable **Admin Mode** as an administrator by using one of these two methods:
- **API**:
```shell
curl --request PUT --header "PRIVATE-TOKEN:$ADMIN_TOKEN" "<gitlab-url>/api/v4/application/settings?admin_mode=false"
```
- [**Rails console**](../../../administration/operations/rails_console.md#starting-a-rails-console-session):
```ruby
::Gitlab::CurrentSettings.update!(admin_mode: false)
```
## Two-factor authentication
When this feature is enabled, all users must use the [two-factor authentication](../../profile/account/two_factor_authentication.md).
After the two-factor authentication is configured as mandatory, users are allowed
to skip forced configuration of two-factor authentication for the configurable grace
period in hours.
![Two-factor grace period](img/two_factor_grace_period.png)
## Email notification for unknown sign-ins
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/218457) in GitLab 13.2.
When enabled, GitLab notifies users of sign-ins from unknown IP addresses or devices. For more information,
see [Email notification for unknown sign-ins](../../profile/notifications.md#notifications-for-unknown-sign-ins).
![Email notification for unknown sign-ins](img/email_notification_for_unknown_sign_ins_v13_2.png)
## Sign-in information
All users that are not logged in are redirected to the page represented by the configured
**Home page URL** if value is not empty.
All users are redirected to the page represented by the configured **Sign-out page URL**
after sign out if value is not empty.
In the **Sign-in restrictions** section, scroll to the **Sign-in text** field. You can add a
custom message for your users in Markdown format.
For example, if you include the following information in the noted text box:
```markdown
# Custom sign-in text
To access this text box:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand the **Sign-in restrictions** section.
```
Your users see the **Custom sign-in text** when they navigate to the sign-in screen for your
GitLab instance.
## Troubleshooting
### Re-enable standard web sign-in form in rails console
Re-enable the standard username and password-based sign-in form if it was disabled as a [Sign-in restriction](#password-authentication-enabled).
You can use this method through the [rails console](../../../administration/operations/rails_console.md#starting-a-rails-console-session) when a configured external authentication provider (through SSO or an LDAP configuration) is facing an outage and direct sign-in access to GitLab is required.
```ruby
Gitlab::CurrentSettings.update!(password_authentication_enabled_for_web: true)
```
<!-- This redirect file can be deleted after <2023-10-13>. -->
<!-- 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 -->

View File

@ -14,7 +14,7 @@ This page contains information about administering the GitLab for Slack app for
The GitLab for Slack app distributed through the Slack App Directory only works with GitLab.com.
On self-managed GitLab, you can create your own copy of the GitLab for Slack app from a [manifest file](https://api.slack.com/reference/manifests#creating_apps) and configure your instance.
The app is a private one-time copy installed in your Slack workspace only and not distributed through the Slack App Directory. To have the [GitLab for Slack app](../../../user/project/integrations/gitlab_slack_application.md) on your self-managed instance, you must first enable the integration.
The app is a private one-time copy installed in your Slack workspace only and not distributed through the Slack App Directory. To have the [GitLab for Slack app](../../../user/project/integrations/gitlab_slack_application.md) on your self-managed instance, you must enable the integration.
## Create a GitLab for Slack app

View File

@ -161,6 +161,10 @@ Prerequisites:
To close an epic, at the top of an epic, select **Close epic**.
<!-- Delete when the `move_close_into_dropdown` feature flag is removed -->
If you don't see this action at the top of an epic, your project or instance might have
enabled a feature flag to [moved it in the actions menu](../../project/issues/managing_issues.md#move-the-close-button-into-the-actions-menu).
You can also use the `/close` [quick action](../../project/quick_actions.md).
## Reopen a closed epic
@ -179,6 +183,10 @@ To do so, either:
- Use the `/reopen` [quick action](../../project/quick_actions.md).
<!-- Delete when the `move_close_into_dropdown` feature flag is removed -->
If you don't see this action at the top of an epic, your project or instance might have
enabled a feature flag to [moved it in the actions menu](../../project/issues/managing_issues.md#move-the-close-button-into-the-actions-menu).
## Go to an epic from an issue
If an issue belongs to an epic, you can go to the parent epic with the

View File

@ -501,7 +501,7 @@ This error occurs in the following scenarios:
- You do not have 2FA enabled but an administrator has enabled the
[enforce 2FA for all users](../../../security/two_factor_authentication.md#enforce-2fa-for-all-users) setting.
- You do not have 2FA enabled, but an administrator has disabled the
[password authentication enabled for Git over HTTP(S)](../../admin_area/settings/sign_in_restrictions.md#password-authentication-enabled)
[password authentication enabled for Git over HTTP(S)](../../../administration/settings/sign_in_restrictions.md#password-authentication-enabled)
setting.
Instead you can authenticate:

View File

@ -290,7 +290,7 @@ To always receive notifications on your own issues, merge requests, and so on, t
NOTE:
This feature is enabled by default for self-managed instances. Administrators may disable this feature
through the [Sign-in restrictions](../admin_area/settings/sign_in_restrictions.md#email-notification-for-unknown-sign-ins) section of the UI.
through the [Sign-in restrictions](../../administration/settings/sign_in_restrictions.md#email-notification-for-unknown-sign-ins) section of the UI.
The feature is always enabled on GitLab.com.
When a user successfully signs in from a previously unknown IP address or device,

View File

@ -20,7 +20,7 @@ you run in Slack is run by your linked GitLab user.
Prerequisites:
- You must have the [appropriate permissions to add apps to your Slack workspace](https://slack.com/help/articles/202035138-Add-apps-to-your-Slack-workspace).
- On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature](../../admin_area/settings/slack_app.md). On GitLab.com, this feature is available.
- On self-managed GitLab, an administrator must [enable the integration](../../admin_area/settings/slack_app.md).
In GitLab 15.0 and later, the GitLab for Slack app uses
[granular permissions](https://medium.com/slack-developer-blog/more-precision-less-restrictions-a3550006f9c3).
@ -176,7 +176,7 @@ The following events are available for Slack notifications:
### GitLab for Slack app does not appear in the list of integrations
The GitLab for Slack app might not appear in the list of integrations. To have the GitLab for Slack app on your self-managed instance, an administrator must first [enable the integration](../../admin_area/settings/slack_app.md). On GitLab.com, the GitLab for Slack app is available by default.
The GitLab for Slack app might not appear in the list of integrations. To have the GitLab for Slack app on your self-managed instance, an administrator must [enable the integration](../../admin_area/settings/slack_app.md). On GitLab.com, the GitLab for Slack app is available by default.
The GitLab for Slack app is enabled at the project level only. Support for the app at the group and instance levels is proposed in [issue 391526](https://gitlab.com/gitlab-org/gitlab/-/issues/391526).

View File

@ -215,6 +215,9 @@ To close an issue, you can either:
1. Select **Plan > Issues**, then select your issue to view it.
1. At the top of the issue, select **Close issue**.
If you don't see this action at the top of an issue, your project or instance might have
enabled a feature flag to [moved it in the actions menu](#move-the-close-button-into-the-actions-menu).
### Reopen a closed issue
Prerequisites:
@ -224,6 +227,9 @@ Prerequisites:
To reopen a closed issue, at the top of the issue, select **Reopen issue**.
A reopened issue is no different from any other open issue.
If you don't see this action at the top of an issue, your project or instance might have
enabled a feature flag to [moved it in the actions menu](#move-the-close-button-into-the-actions-menu).
### Closing issues automatically
You can close issues automatically by using certain words, called a _closing pattern_,
@ -324,6 +330,24 @@ Prerequisites:
Learn how to change the default [issue closing pattern](../../../administration/issue_closing_pattern.md).
of your installation.
<!-- Delete when the `move_close_into_dropdown` feature flag is removed
and update steps for closing and reopening issues, incidents, and epics -->
### Move the close button into the actions menu
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/125173) in GitLab 16.2 [with a flag](../../../administration/feature_flags.md) named `move_close_into_dropdown`. Disabled by default.
FLAG:
On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../../../administration/feature_flags.md) named `move_close_into_dropdown`.
On GitLab.com, this feature is not available.
When this feature flag is enabled, in the upper-right corner,
**Issue actions** (**{ellipsis_v}**) contains the **Close issue** and **Reopen issue** actions.
In GitLab 16.2 and later, similar action menus are also available on incidents and epics.
When this feature flag is disabled, **Close issue** and **Reopen issue** are
on the top bar, outside of the actions menu.
## Change the issue type
Prerequisites:

View File

@ -80,7 +80,7 @@ and rights into the group or project.
| View milestones of groups higher in the hierarchy | ✓ | ✓ | ✓ | ✓ |
| Be shared into other groups | ✓ | | | |
| Be shared into other projects | ✓ | ✓ | | |
| Share the group with other members | ✓ | | | |
| Share the group with other members | ✓ | | | |
In the following example, `User` is a:

View File

@ -112,7 +112,7 @@ permission enables an electronic signature for approvals, such as the one define
[Code of Federal Regulations (CFR) Part 11](https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?CFRPart=11&showFR=1&subpartNode=21:1.0.1.1.8.3)):
1. Enable password authentication for the web interface, as described in the
[sign-in restrictions documentation](../../../admin_area/settings/sign_in_restrictions.md#password-authentication-enabled).
[sign-in restrictions documentation](../../../../administration/settings/sign_in_restrictions.md#password-authentication-enabled).
1. On the left sidebar, select **Settings > Merge requests**.
1. In the **Merge request approvals** section, scroll to **Approval settings** and
select **Require user password to approve**.

View File

@ -163,7 +163,7 @@ The following quick actions can be applied through the description field when ed
| `/clear_health_status` | **{check-circle}** Yes | **{dotted-circle}** Yes | **{dotted-circle}** Yes | Clear [health status](issues/managing_issues.md#health-status).
| `/weight <value>` | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Set weight. Valid options for `<value>` include `0`, `1`, and `2`.
| `/clear_weight` | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Clear weight.
| `/type` | **{check-circle}** Yes | **{dotted-circle}** Yes | **{dotted-circle}** Yes | Converts work item to specified type. Available options for `<type>` include `Issue`, `Task`, `Objective` and `Key Result`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/385227) in GitLab 16.0.
| `/type` | **{check-circle}** Yes | **{dotted-circle}** Yes | **{dotted-circle}** Yes | Converts work item to specified type. Available options for `<type>` include `issue`, `task`, `objective` and `key result`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/385227) in GitLab 16.0.
| `/promote_to <type>` | **{check-circle}** Yes | **{dotted-circle}** No | **{check-circle}** Yes | Promotes work item to specified type. Available options for `<type>`: `issue` (promote a task) and `objective` (promote a key result). [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/412534) in GitLab 16.1.
| `/todo` | **{check-circle}** Yes | **{check-circle}** Yes | **{check-circle}** Yes | Add a to-do item. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/412277) in GitLab 16.2.
| `/done` | **{check-circle}** Yes | **{check-circle}** Yes | **{check-circle}** Yes | Mark to-do item as done. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/412277) in GitLab 16.2.

View File

@ -27,7 +27,7 @@ can limit the search scope by disabling the following [`ops` feature flags](../.
| Issues | `global_search_issues_tab` | When enabled, global search includes issues. |
| Merge requests | `global_search_merge_requests_tab` | When enabled, global search includes merge requests. |
| Users | `global_search_users_tab` | When enabled, global search includes users. |
| Wiki | `global_search_wiki_tab` | When enabled, global search includes project and group wikis. |
| Wiki | `global_search_wiki_tab` | When enabled, global search includes project and [group wikis](../project/wiki/group.md). |
All global search scopes are enabled by default on self-managed instances.

View File

@ -98,7 +98,7 @@ module Gitlab
def success_msg
{
type: _('Type changed successfully.'),
promote_to: _("Work Item promoted successfully.")
promote_to: _("Work item promoted successfully.")
}
end
end

View File

@ -25888,7 +25888,7 @@ msgstr ""
msgid "JiraConnect|No linked groups"
msgstr ""
msgid "JiraConnect|Not seeing your groups? Only groups you have access to appear here."
msgid "JiraConnect|Not seeing your groups? Only groups you have at least the Maintainer role for appear here."
msgstr ""
msgid "JiraConnect|Setting up this integration is only possible if you're a GitLab administrator."
@ -40476,6 +40476,9 @@ msgstr ""
msgid "ScanExecutionPolicy|%{rules} every time a pipeline runs for %{scopes} %{branches} %{agents} %{namespaces}"
msgstr ""
msgid "ScanExecutionPolicy|A runner will be selected automatically from those available."
msgstr ""
msgid "ScanExecutionPolicy|Add condition"
msgstr ""
@ -40491,9 +40494,6 @@ msgstr ""
msgid "ScanExecutionPolicy|Customized variables will overwrite ones defined in the project CI/CD file and settings"
msgstr ""
msgid "ScanExecutionPolicy|If the field is empty, the runner will be automatically selected"
msgstr ""
msgid "ScanExecutionPolicy|Key"
msgstr ""
@ -40503,13 +40503,22 @@ msgstr ""
msgid "ScanExecutionPolicy|Maximum number of CI-criteria is one"
msgstr ""
msgid "ScanExecutionPolicy|Maximum number of runner tags-criteria is one"
msgstr ""
msgid "ScanExecutionPolicy|Only one variable can be added at a time."
msgstr ""
msgid "ScanExecutionPolicy|Run a %{scan} scan on runner that %{tags}"
msgid "ScanExecutionPolicy|Run a %{scan} scan with %{dastProfiles} with the following options:"
msgstr ""
msgid "ScanExecutionPolicy|Run a %{scan} scan with %{dastProfiles} on runner that %{tags}"
msgid "ScanExecutionPolicy|Run a %{scan} scan with the following options:"
msgstr ""
msgid "ScanExecutionPolicy|Runner tags"
msgstr ""
msgid "ScanExecutionPolicy|Runner tags:"
msgstr ""
msgid "ScanExecutionPolicy|Scanner profile"
@ -51944,9 +51953,6 @@ msgstr ""
msgid "Won't fix / Accept risk"
msgstr ""
msgid "Work Item promoted successfully."
msgstr ""
msgid "Work Item type with id %{id} was not found"
msgstr ""
@ -51956,6 +51962,9 @@ msgstr ""
msgid "Work in progress limit"
msgstr ""
msgid "Work item promoted successfully."
msgstr ""
msgid "WorkItem|%{count} more assignees"
msgstr ""

View File

@ -73,6 +73,7 @@ module QA
end
def collapse_replies
close_rich_text_promo_popover_if_present
click_element :collapse_replies_button
end

View File

@ -381,6 +381,7 @@ module QA
end
def try_to_merge!
close_rich_text_promo_popover_if_present
# Revisit after merge page re-architect is done https://gitlab.com/gitlab-org/gitlab/-/issues/300042
# To remove page refresh logic if possible
wait_until_ready_to_merge

View File

@ -22,6 +22,10 @@ RSpec.describe 'Related issues', :js, feature_category: :team_planning do
let_it_be(:private_issue) { create(:issue, project: private_project) }
let_it_be(:public_issue) { create(:issue, project: public_project) }
before do
stub_feature_flags(move_close_into_dropdown: false)
end
context 'widget visibility' do
context 'when not logged in' do
it 'does not show widget when internal project' do

View File

@ -50,7 +50,9 @@ RSpec.describe 'User uses search filters', :js, feature_category: :global_search
wait_for_requests
expect(page).to have_current_path(search_path(search: "test"))
expect(page).to have_current_path(search_path, ignore_query: true) do |uri|
uri.normalized_query(:sorted) == "scope=blobs&search=test"
end
end
end
end
@ -83,7 +85,9 @@ RSpec.describe 'User uses search filters', :js, feature_category: :global_search
find('[data-testid="project-filter"] [data-testid="clear-icon"]').click
wait_for_requests
expect(page).to have_current_path(search_path(search: "test"))
expect(page).to have_current_path(search_path, ignore_query: true) do |uri|
uri.normalized_query(:sorted) == "scope=blobs&search=test"
end
end
end
end

View File

@ -902,3 +902,5 @@ export const MOCK_FILTERED_UNAPPLIED_SELECTED_LABELS = [
parent_full_name: 'Toolbox / Gitlab Smoke Tests',
},
];
export const CURRENT_SCOPE = 'blobs';

View File

@ -1,7 +1,7 @@
import { shallowMount } from '@vue/test-utils';
import Vue from 'vue';
import Vuex from 'vuex';
import { MOCK_GROUP, MOCK_QUERY } from 'jest/search/mock_data';
import { MOCK_GROUP, MOCK_QUERY, CURRENT_SCOPE } from 'jest/search/mock_data';
import { visitUrl, setUrlParams } from '~/lib/utils/url_utility';
import { GROUPS_LOCAL_STORAGE_KEY } from '~/search/store/constants';
import GroupFilter from '~/search/topbar/components/group_filter.vue';
@ -37,6 +37,7 @@ describe('GroupFilter', () => {
actions: actionSpies,
getters: {
frequentGroups: () => [],
currentScope: () => CURRENT_SCOPE,
},
});
@ -89,6 +90,7 @@ describe('GroupFilter', () => {
[GROUP_DATA.queryParam]: null,
[PROJECT_DATA.queryParam]: null,
nav_source: null,
scope: CURRENT_SCOPE,
});
expect(visitUrl).toHaveBeenCalled();
@ -109,6 +111,7 @@ describe('GroupFilter', () => {
[GROUP_DATA.queryParam]: MOCK_GROUP.id,
[PROJECT_DATA.queryParam]: null,
nav_source: null,
scope: CURRENT_SCOPE,
});
expect(visitUrl).toHaveBeenCalled();

View File

@ -1,7 +1,7 @@
import { shallowMount } from '@vue/test-utils';
import Vue from 'vue';
import Vuex from 'vuex';
import { MOCK_PROJECT, MOCK_QUERY } from 'jest/search/mock_data';
import { MOCK_PROJECT, MOCK_QUERY, CURRENT_SCOPE } from 'jest/search/mock_data';
import { visitUrl, setUrlParams } from '~/lib/utils/url_utility';
import { PROJECTS_LOCAL_STORAGE_KEY } from '~/search/store/constants';
import ProjectFilter from '~/search/topbar/components/project_filter.vue';
@ -37,6 +37,7 @@ describe('ProjectFilter', () => {
actions: actionSpies,
getters: {
frequentProjects: () => [],
currentScope: () => CURRENT_SCOPE,
},
});
@ -88,6 +89,7 @@ describe('ProjectFilter', () => {
expect(setUrlParams).toHaveBeenCalledWith({
[PROJECT_DATA.queryParam]: null,
nav_source: null,
scope: CURRENT_SCOPE,
});
expect(visitUrl).toHaveBeenCalled();
});
@ -107,6 +109,7 @@ describe('ProjectFilter', () => {
[GROUP_DATA.queryParam]: MOCK_PROJECT.namespace.id,
[PROJECT_DATA.queryParam]: MOCK_PROJECT.id,
nav_source: null,
scope: CURRENT_SCOPE,
});
expect(visitUrl).toHaveBeenCalled();
});

View File

@ -75,10 +75,6 @@ RSpec.describe JiraConnectHelper, feature_category: :integrations do
end
end
it 'passes "all_available" param to groups_path' do
expect(subject[:groups_path]).to include('all_available=true')
end
it 'passes group as "skip_groups" param' do
skip_groups_param = CGI.escape('skip_groups[]')

View File

@ -40,7 +40,7 @@ RSpec.describe WebHooks::WebHooksHelper, :clean_gitlab_redis_shared_state, featu
include_context 'a hook has failed'
it 'is true' do
expect(helper).to be_show_project_hook_failed_callout(project: project)
expect(helper.show_project_hook_failed_callout?(project: project)).to eq(true)
end
it 'stores a value' do
@ -64,7 +64,7 @@ RSpec.describe WebHooks::WebHooksHelper, :clean_gitlab_redis_shared_state, featu
contexts.each { |ctx| include_context(ctx) unless ctx == name }
it 'is false' do
expect(helper).not_to be_show_project_hook_failed_callout(project: project)
expect(helper.show_project_hook_failed_callout?(project: project)).to eq(false)
end
end
end

View File

@ -3435,7 +3435,7 @@ module Gitlab
it 'returns errors and empty configuration' do
expect(subject.valid?).to eq(false)
expect(subject.errors).to eq(['Unknown alias: bad_alias'])
expect(subject.errors).to all match(%r{unknown .+ bad_alias}i)
end
end

View File

@ -75,7 +75,7 @@ RSpec.describe Gitlab::Config::Loader::Yaml, feature_category: :pipeline_composi
it 'raises FormatError' do
expect { loader }.to raise_error(
Gitlab::Config::Loader::FormatError,
'Unknown alias: bad_alias'
%r{unknown .+ bad_alias}i
)
end
end

View File

@ -9,7 +9,9 @@ RSpec.describe Gitlab::ErrorTracking::Processor::SanitizeErrorMessageProcessor,
shared_examples 'processes the exception' do
it 'cleans the exception message' do
expect(Gitlab::Sanitizers::ExceptionMessage).to receive(:clean).with('StandardError', 'raw error').and_return('cleaned')
expect(Gitlab::Sanitizers::ExceptionMessage).to receive(:clean).with(
'StandardError', match('raw error')
).and_return('cleaned')
expect(result_hash[:exception][:values].first).to include(
type: 'StandardError',

View File

@ -136,7 +136,7 @@ RSpec.describe Gitlab::Memory::Reporter, :aggregate_failures, feature_category:
end
context 'when cause was compression command failing' do
let(:error_message) { "StandardError: exit 1: cat:" }
let(:error_message) { "StandardError.+exit 1: cat:" }
before do
stub_const('Gitlab::Memory::Reporter::COMPRESS_CMD', %w[cat --bad-flag])

View File

@ -839,14 +839,14 @@ RSpec.describe 'Update a work item', feature_category: :team_planning do
context 'when changing work item type' do
let_it_be(:work_item) { create(:work_item, :task, project: project) }
let(:description) { "/type Issue" }
let(:description) { "/type issue" }
let(:input) { { 'descriptionWidget' => { 'description' => description } } }
context 'with multiple commands' do
let_it_be(:work_item) { create(:work_item, :task, project: project) }
let(:description) { "Updating work item\n/type Issue\n/due tomorrow\n/title Foo" }
let(:description) { "Updating work item\n/type issue\n/due tomorrow\n/title Foo" }
it 'updates the work item type and other attributes' do
expect do

View File

@ -503,4 +503,51 @@ RSpec.describe 'getting user information', feature_category: :user_management do
end
end
end
context 'authored merge requests' do
let_it_be(:current_user) { create(:user) }
let_it_be(:group) { create(:group) }
let_it_be(:subgroup) { create(:group, parent: group) }
let_it_be(:project) { create(:project, :public, group: group) }
let_it_be(:merge_request1) do
create(:merge_request, source_project: project, source_branch: '1', author: current_user)
end
let_it_be(:merge_request2) do
create(:merge_request, source_project: project, source_branch: '2', author: current_user)
end
let_it_be(:merge_request_different_user) do
create(:merge_request, source_project: project, source_branch: '3', author: create(:user))
end
let_it_be(:merge_request_different_group) do
create(:merge_request, source_project: create(:project, :public), author: current_user)
end
let_it_be(:merge_request_subgroup) do
create(:merge_request, source_project: create(:project, :public, group: subgroup), author: current_user)
end
let(:query) do
%(
query {
currentUser {
authoredMergeRequests(groupId: "#{group.to_global_id}") {
nodes {
id
}
}
}
}
)
end
it 'returns merge requests for the current user for the specified group' do
post_graphql(query, current_user: current_user)
expect(graphql_data_at(:current_user, :authored_merge_requests, :nodes).pluck('id')).to contain_exactly(
merge_request1.to_global_id.to_s, merge_request2.to_global_id.to_s, merge_request_subgroup.to_global_id.to_s)
end
end
end

View File

@ -2872,13 +2872,13 @@ RSpec.describe QuickActions::InterpretService, feature_category: :team_planning
let_it_be(:project) { create(:project, :private) }
let_it_be(:work_item) { create(:work_item, :task, project: project) }
let(:command) { '/type Issue' }
let(:command) { '/type issue' }
it 'has command available' do
_, explanations = service.explain(command, work_item)
expect(explanations)
.to contain_exactly("Converts work item to Issue. Widgets not supported in new type are removed.")
.to contain_exactly("Converts work item to issue. Widgets not supported in new type are removed.")
end
end

View File

@ -157,7 +157,7 @@ RSpec.shared_examples 'work item supports type change via quick actions' do
let_it_be(:assignee) { create(:user) }
let_it_be(:task_type) { WorkItems::Type.default_by_type(:task) }
let(:body) { "Updating type.\n/type Issue" }
let(:body) { "Updating type.\n/type issue" }
before do
noteable.update!(work_item_type: task_type)
@ -211,4 +211,15 @@ RSpec.shared_examples 'work item supports type change via quick actions' do
.to include("Commands only Type changed successfully. Assigned @#{assignee.username}.")
end
end
context 'when the type name is upper case' do
let(:body) { "Updating type.\n/type Issue" }
it 'changes type to issue' do
expect do
post_graphql_mutation(mutation, current_user: current_user)
noteable.reload
end.to change { noteable.work_item_type.base_type }.from('task').to('issue')
end
end
end

View File

@ -20,7 +20,7 @@ RSpec.shared_examples 'quick actions that change work item type' do
end
context 'when new type is the same as current type' do
let(:command) { '/type Issue' }
let(:command) { '/type issue' }
it_behaves_like 'quick command error', 'Types are the same'
end
@ -57,7 +57,7 @@ RSpec.shared_examples 'quick actions that change work item type' do
it 'populates :issue_type: and :work_item_type' do
_, updates, message = service.execute(command, work_item)
expect(message).to eq(_('Work Item promoted successfully.'))
expect(message).to eq(_('Work item promoted successfully.'))
expect(updates).to eq({ issue_type: 'incident', work_item_type: WorkItems::Type.default_by_type(:incident) })
end
@ -73,7 +73,7 @@ RSpec.shared_examples 'quick actions that change work item type' do
it 'populates :issue_type: and :work_item_type' do
_, updates, message = service.execute(command, work_item)
expect(message).to eq(_('Work Item promoted successfully.'))
expect(message).to eq(_('Work item promoted successfully.'))
expect(updates).to eq({ issue_type: 'issue', work_item_type: WorkItems::Type.default_by_type(:issue) })
end

View File

@ -85,6 +85,7 @@ RSpec.describe Tooling::Danger::ProjectHelper do
'.rubocop.yml' | [:backend]
'.rubocop_todo.yml' | [:backend]
'.rubocop_todo/cop/name.yml' | [:backend]
'gems/foo/.rubocop.yml' | [:backend]
'spec/foo' | [:backend]
'spec/foo/bar' | [:backend]
@ -141,6 +142,8 @@ RSpec.describe Tooling::Danger::ProjectHelper do
'tooling/bin/find_foss_tests' | [:tooling]
'.codeclimate.yml' | [:tooling]
'.gitlab/CODEOWNERS' | [:tooling]
'gems/gem.gitlab-ci.yml' | [:tooling]
'gems/config/rubocop.yml' | [:tooling]
'lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml' | [:ci_template]
'lib/gitlab/ci/templates/dotNET-Core.yml' | [:ci_template]

View File

@ -39,10 +39,10 @@ RSpec.describe Ci::PipelineCleanupRefWorker, :sidekiq_inline, feature_category:
expect(persistent_ref).not_to receive(:delete_refs)
end
expect(worker).to receive(:in_lock).and_wrap_original do |method, *args, &block|
expect(worker).to receive(:in_lock).and_wrap_original do |method, *args, **kwargs, &block|
pipeline.run!
method.call(*args, &block)
method.call(*args, **kwargs, &block)
end
subject

View File

@ -113,6 +113,8 @@ module Tooling
%r{\A\.editorconfig\z} => :tooling,
%r{Dangerfile\z} => :tooling,
%r{\A((ee|jh)/)?(danger/|tooling/danger/)} => :tooling,
%r{\Agems/gem\.gitlab-ci\.yml\z} => :tooling,
%r{\Agems/config/} => :tooling,
%r{\A((ee|jh)/)?scripts/(lib/)?glfm/.*\.rb} => [:backend],
%r{\A((ee|jh)/)?scripts/(lib/)?glfm/.*\.js} => [:frontend],
@ -162,6 +164,7 @@ module Tooling
%r{\A(Gemfile.*|Rakefile)\z} => :backend,
%r{\A[A-Z_]+_VERSION\z} => :backend,
%r{\A\.rubocop(_todo)?\.yml\z} => :backend,
%r{\Agems/.*/\.rubocop\.yml\z} => :backend,
%r{\A\.rubocop_todo/.*\.yml\z} => :backend,
%r{\Afile_hooks/} => :backend,