Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2021-12-15 12:10:49 +00:00
parent 5cad106998
commit 73b652cf4f
10 changed files with 16 additions and 119 deletions

View File

@ -1,20 +0,0 @@
.flex-list
.flex-row
= image_tag avatar_icon_for_user(user), class: 'avatar s32 d-none d-md-flex', alt: _('Avatar for %{name}') % { name: sanitize_name(user.name) }
.row-main-content
.row-title.str-truncated-100
= image_tag avatar_icon_for_user(user), class: 'avatar s16 d-xs-flex d-md-none mr-1 gl-mt-2', alt: _('Avatar for %{name}') % { name: sanitize_name(user.name) }
= link_to user.name, admin_user_path(user), class: 'text-plain js-user-link', data: { user_id: user.id, qa_selector: 'username_link' }
= render 'admin/users/user_listing_note', user: user
- user_badges_in_admin_section(user).each do |badge|
- css_badge = "badge gl-badge sm badge-pill badge-#{badge[:variant]}" if badge[:variant].present?
%span.px-1.py-1
%span{ class: css_badge }
= badge[:text]
.row-second-line.str-truncated-100
= mail_to user.email, user.email, class: 'text-secondary'
- unless Feature.disabled?(:security_auto_fix) || !user.internal? || user.website_url.blank?
= link_to "(#{_('more information')})", user.website_url

View File

@ -166,7 +166,7 @@ that can also be promoted in case of disaster.
## Deviating from the suggested reference architectures
As a general rule of thumb, the further away you move from the Reference Architectures,
As a general guideline, the further away you move from the Reference Architectures,
the harder it will be get support for it. With any deviation, you're introducing
a layer of complexity that will add challenges to finding out where potential
issues might lie.

View File

@ -308,7 +308,7 @@ This folder holds all components that are specific to this new feature.
If you need to use or create a component that is likely to be used somewhere
else, please refer to `vue_shared/components`.
A good rule of thumb to know when you should create a component is to think if
A good guideline to know when you should create a component is to think if
it could be reusable elsewhere.
For example, tables are used in a quite amount of places across GitLab, a table
@ -336,7 +336,7 @@ In the [Vue documentation](https://vuejs.org/v2/api/#Options-Data) the Data func
> The data object for the Vue instance. Vue recursively converts its properties into getter/setters
to make it "reactive". The object must be plain: native objects such as browser API objects and
prototype properties are ignored. A rule of thumb is that data should just be data - it is not
prototype properties are ignored. A guideline is that data should just be data - it is not
recommended to observe objects with their own stateful behavior.
Based on the Vue guidance:

View File

@ -57,7 +57,7 @@ Redis version 6.0 or higher is recommended, as this is what ships with
### Storage
The necessary hard drive space largely depends on the size of the repositories you want to store in GitLab but as a *rule of thumb* you should have at least as much free space as all your repositories combined take up.
The necessary hard drive space largely depends on the size of the repositories you want to store in GitLab but as a *guideline* you should have at least as much free space as all your repositories combined take up.
The Omnibus GitLab package requires about 2.5 GB of storage space for installation.

View File

@ -33,6 +33,14 @@ Refer to the [OAuth guide](oauth_provider.md) for basic information on how to se
applications in GitLab. To enable OIDC for an application, all you have to do
is select the `openid` scope in the application settings.
## Settings discovery
If your client allows importing OIDC settings from a discovery URL, you can use the following URL to automatically find the correct settings:
```plaintext
https://gitlab.example.com/.well-known/openid-configuration
```
## Shared information
The following user information is shared with clients:

View File

@ -56,7 +56,7 @@ increasing the number of Sidekiq workers that can process jobs in the
`background_migration` queue. To see the size of this queue,
[Check for background migrations before upgrading](index.md#checking-for-background-migrations-before-upgrading).
As a rule of thumb, any database smaller than 10 GB doesn't take too much time to
As a guideline, any database smaller than 10 GB doesn't take too much time to
upgrade; perhaps an hour at most per minor release. Larger databases however may
require more time, but this is highly dependent on the size of the database and
the migrations that are being performed.

View File

@ -5181,9 +5181,6 @@ msgstr ""
msgid "Avatar for %{assigneeName}"
msgstr ""
msgid "Avatar for %{name}"
msgstr ""
msgid "Avatar will be removed. Are you sure?"
msgstr ""
@ -41888,9 +41885,6 @@ msgstr ""
msgid "missing"
msgstr ""
msgid "more information"
msgstr ""
msgid "most recent deployment"
msgstr ""

View File

@ -15,10 +15,6 @@ module QA
element :user_row_content
end
view 'app/views/admin/users/_user_detail.html.haml' do
element :username_link
end
def search_user(username)
find_element(:user_search_field).set(username).send_keys(:return)
end

View File

@ -289,9 +289,9 @@ HELM_CMD=$(cat << EOF
--set releaseOverride="${release}" \
--set global.hosts.hostSuffix="${HOST_SUFFIX}" \
--set global.hosts.domain="${REVIEW_APPS_DOMAIN}" \
--set global.sentry.enabled="${sentry_enabled}" \
--set global.sentry.dsn="${REVIEW_APPS_SENTRY_DSN}" \
--set global.sentry.environment="review" \
--set global.appConfig.sentry.enabled="${sentry_enabled}" \
--set global.appConfig.sentry.dsn="${REVIEW_APPS_SENTRY_DSN}" \
--set global.appConfig.sentry.environment="review" \
--set gitlab.migrations.image.repository="${gitlab_toolbox_image_repository}" \
--set gitlab.migrations.image.tag="${CI_COMMIT_REF_SLUG}" \
--set gitlab.gitaly.image.repository="${gitlab_gitaly_image_repository}" \

View File

@ -1,81 +0,0 @@
# frozen_string_literal: true
require 'fast_spec_helper'
require_relative '../../../scripts/lib/gitlab'
RSpec.describe 'scripts/lib/gitlab.rb' do
let(:ee_file_path) { File.expand_path('../../../ee/app/models/license.rb', __dir__) }
describe '.ee?' do
before do
stub_env('FOSS_ONLY', nil)
allow(File).to receive(:exist?).with(ee_file_path) { true }
end
it 'returns true when ee/app/models/license.rb exists' do
expect(Gitlab.ee?).to eq(true)
end
end
describe '.jh?' do
context 'when jh directory exists and EE_ONLY is not set' do
before do
stub_env('EE_ONLY', nil)
allow(Dir).to receive(:exist?).with(File.expand_path('../../../jh', __dir__)) { true }
end
context 'when ee/app/models/license.rb exists' do
before do
allow(File).to receive(:exist?).with(ee_file_path) { true }
end
context 'when FOSS_ONLY is not set' do
before do
stub_env('FOSS_ONLY', nil)
end
it 'returns true' do
expect(Gitlab.jh?).to eq(true)
end
end
context 'when FOSS_ONLY is set to 1' do
before do
stub_env('FOSS_ONLY', '1')
end
it 'returns false' do
expect(Gitlab.jh?).to eq(false)
end
end
end
context 'when ee/app/models/license.rb not exist' do
before do
allow(File).to receive(:exist?).with(ee_file_path) { false }
end
context 'when FOSS_ONLY is not set' do
before do
stub_env('FOSS_ONLY', nil)
end
it 'returns true' do
expect(Gitlab.jh?).to eq(false)
end
end
context 'when FOSS_ONLY is set to 1' do
before do
stub_env('FOSS_ONLY', '1')
end
it 'returns false' do
expect(Gitlab.jh?).to eq(false)
end
end
end
end
end
end