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

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2021-06-10 12:10:09 +00:00
parent 67b0b1c43f
commit c68905777e
105 changed files with 2782 additions and 2259 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
app/assets/javascripts/pipeline_editor/components/code_snippet_alert/constants.js
View File

@ -2,10 +2,16 @@ import { helpPagePath } from '~/helpers/help_page_helper';
export const CODE_SNIPPET_SOURCE_URL_PARAM = 'code_snippet_copied_from';
export const CODE_SNIPPET_SOURCE_API_FUZZING = 'api_fuzzing';
export const CODE_SNIPPET_SOURCES = [CODE_SNIPPET_SOURCE_API_FUZZING];
export const CODE_SNIPPET_SOURCE_DAST = 'dast';
export const CODE_SNIPPET_SOURCES = [CODE_SNIPPET_SOURCE_API_FUZZING, CODE_SNIPPET_SOURCE_DAST];
export const CODE_SNIPPET_SOURCE_SETTINGS = {
[CODE_SNIPPET_SOURCE_API_FUZZING]: {
datasetKey: 'apiFuzzingConfigurationPath',
docsPath: helpPagePath('user/application_security/api_fuzzing/index'),
},
[CODE_SNIPPET_SOURCE_DAST]: {
datasetKey: 'dastConfigurationPath',
docsPath: helpPagePath('user/application_security/dast/index'),
},
};

32
app/assets/javascripts/releases/components/app_index_apollo_client.vue
View File

@ -1,10 +1,11 @@
<script>
import { GlButton } from '@gitlab/ui';
import createFlash from '~/flash';
import { getParameterByName } from '~/lib/utils/common_utils';
import { historyPushState, getParameterByName } from '~/lib/utils/common_utils';
import { scrollUp } from '~/lib/utils/scroll_utils';
import { setUrlParams } from '~/lib/utils/url_utility';
import { __ } from '~/locale';
import { PAGE_SIZE, RELEASED_AT_DESC } from '~/releases/constants';
import { PAGE_SIZE, DEFAULT_SORT } from '~/releases/constants';
import allReleasesQuery from '~/releases/graphql/queries/all_releases.query.graphql';
import { convertAllReleasesGraphQLResponse } from '~/releases/util';
import ReleaseBlock from './release_block.vue';
@ -58,7 +59,7 @@ export default {
before: getParameterByName('before'),
after: getParameterByName('after'),
},
sort: RELEASED_AT_DESC,
sort: DEFAULT_SORT,
};
},
computed: {
@ -145,6 +146,29 @@ export default {
// scroll to the top of the page every time a pagination button is pressed.
scrollUp();
},
onSortChanged(newSort) {
if (this.sort === newSort) {
return;
}
// Remove the "before" and "after" query parameters from the URL,
// effectively placing the user back on page 1 of the results.
// This prevents the frontend from requesting the results sorted
// by one field (e.g. `released_at`) while using a pagination cursor
// intended for a different field (e.g.) `created_at`).
// For more details, see the MR that introduced this change:
// https://gitlab.com/gitlab-org/gitlab/-/merge_requests/63434
historyPushState(
setUrlParams({
before: null,
after: null,
}),
);
this.updateQueryParamsFromUrl();
this.sort = newSort;
},
},
i18n: {
newRelease: __('New release'),
@ -155,7 +179,7 @@ export default {
<template>
<div class="flex flex-column mt-2">
<div class="gl-align-self-end gl-mb-3">
<releases-sort-apollo-client v-model="sort" class="gl-mr-2" />
<releases-sort-apollo-client :value="sort" class="gl-mr-2" @input="onSortChanged" />
<gl-button
v-if="newReleasePath"

2
app/assets/javascripts/releases/constants.js
View File

@ -47,3 +47,5 @@ export const SORT_MAP = {
[DESCENDING_ORDER]: CREATED_DESC,
},
};
export const DEFAULT_SORT = RELEASED_AT_DESC;

52
app/assets/javascripts/search/topbar/components/searchable_dropdown.vue
View File

@ -8,12 +8,10 @@ import {
GlButton,
GlSkeletonLoader,
GlTooltipDirective,
GlAvatar,
} from '@gitlab/ui';
import highlight from '~/lib/utils/highlight';
import { truncateNamespace } from '~/lib/utils/text_utility';
import { __ } from '~/locale';
import { ANY_OPTION } from '../constants';
import SearchableDropdownItem from './searchable_dropdown_item.vue';
export default {
i18n: {
@ -28,7 +26,7 @@ export default {
GlIcon,
GlButton,
GlSkeletonLoader,
GlAvatar,
SearchableDropdownItem,
},
directives: {
GlTooltip: GlTooltipDirective,
@ -79,11 +77,8 @@ export default {
resetDropdown() {
this.$emit('change', ANY_OPTION);
},
truncateNamespace(namespace) {
return truncateNamespace(namespace);
},
highlightedItemName(name) {
return highlight(name, this.searchText);
updateDropdown(item) {
this.$emit('change', item);
},
},
ANY_OPTION,
@ -97,7 +92,7 @@ export default {
toggle-class="gl-text-truncate"
:header-text="headerText"
:right="true"
@show="$emit('search', searchText)"
@show="openDropdown"
@shown="$refs.searchBox.focusInput()"
>
<template #button-content>
@ -126,46 +121,29 @@ export default {
v-model="searchText"
class="gl-m-3"
:debounce="500"
@input="$emit('search', searchText)"
@input="openDropdown"
/>
<gl-dropdown-item
class="gl-border-b-solid gl-border-b-gray-100 gl-border-b-1 gl-pb-2! gl-mb-2"
:is-check-item="true"
:is-checked="isSelected($options.ANY_OPTION)"
:is-check-centered="true"
@click="resetDropdown"
@click="updateDropdown($options.ANY_OPTION)"
>
<span data-testid="item-title">{{ $options.ANY_OPTION.name }}</span>
</gl-dropdown-item>
</div>
<div v-if="!loading">
<gl-dropdown-item
<searchable-dropdown-item
v-for="item in items"
:key="item.id"
:is-check-item="true"
:is-checked="isSelected(item)"
:is-check-centered="true"
@click="$emit('change', item)"
>
<div class="gl-display-flex gl-align-items-center">
<gl-avatar
:src="item.avatar_url"
:entity-id="item.id"
:entity-name="item[name]"
shape="rect"
:size="32"
/>
<div class="gl-display-flex gl-flex-direction-column">
<!-- eslint-disable-next-line vue/no-v-html -->
<span data-testid="item-title" v-html="highlightedItemName(item[name])">{{
item[name]
}}</span>
<span class="gl-font-sm gl-text-gray-700" data-testid="item-namespace">{{
truncateNamespace(item[fullName])
}}</span>
</div>
</div>
</gl-dropdown-item>
:item="item"
:selected-item="selectedItem"
:search-text="searchText"
:name="name"
:full-name="fullName"
@change="updateDropdown"
/>
</div>
<div v-if="loading" class="gl-mx-4 gl-mt-3">
<gl-skeleton-loader :height="100">

73
app/assets/javascripts/search/topbar/components/searchable_dropdown_item.vue Normal file
View File

@ -0,0 +1,73 @@
<script>
import { GlDropdownItem, GlAvatar } from '@gitlab/ui';
import highlight from '~/lib/utils/highlight';
import { truncateNamespace } from '~/lib/utils/text_utility';
export default {
name: 'SearchableDropdownItem',
components: {
GlDropdownItem,
GlAvatar,
},
props: {
item: {
type: Object,
required: true,
},
selectedItem: {
type: Object,
required: true,
},
searchText: {
type: String,
required: false,
default: '',
},
name: {
type: String,
required: true,
},
fullName: {
type: String,
required: true,
},
},
computed: {
isSelected() {
return this.item.id === this.selectedItem.id;
},
truncatedNamespace() {
return truncateNamespace(this.item[this.fullName]);
},
highlightedItemName() {
return highlight(this.item[this.name], this.searchText);
},
},
};
</script>
<template>
<gl-dropdown-item
:is-check-item="true"
:is-checked="isSelected"
:is-check-centered="true"
@click="$emit('change', item)"
>
<div class="gl-display-flex gl-align-items-center">
<gl-avatar
:src="item.avatar_url"
:entity-id="item.id"
:entity-name="item[name]"
shape="rect"
:size="32"
/>
<div class="gl-display-flex gl-flex-direction-column">
<!-- eslint-disable-next-line vue/no-v-html -->
<span data-testid="item-title" v-html="highlightedItemName">{{ item[name] }}</span>
<span class="gl-font-sm gl-text-gray-700" data-testid="item-namespace">{{
truncatedNamespace
}}</span>
</div>
</div>
</gl-dropdown-item>
</template>

7
app/graphql/mutations/todos/mark_all_done.rb
View File

@ -7,12 +7,6 @@ module Mutations
authorize :update_user
field :updated_ids,
[::Types::GlobalIDType[::Todo]],
null: false,
deprecated: { reason: 'Use to-do items', milestone: '13.2' },
description: 'IDs of the updated to-do items.'
field :todos, [::Types::TodoType],
null: false,
description: 'Updated to-do items.'
@ -23,7 +17,6 @@ module Mutations
updated_ids = mark_all_todos_done
{
updated_ids: updated_ids,
todos: Todo.id_in(updated_ids),
errors: []
}

5
app/graphql/mutations/todos/restore_many.rb
View File

@ -12,11 +12,6 @@ module Mutations
required: true,
description: 'The global IDs of the to-do items to restore (a maximum of 50 is supported at once).'
field :updated_ids, [::Types::GlobalIDType[Todo]],
null: false,
description: 'The IDs of the updated to-do items.',
deprecated: { reason: 'Use to-do items', milestone: '13.2' }
field :todos, [::Types::TodoType],
null: false,
description: 'Updated to-do items.'

10
app/graphql/types/deprecated_mutations.rb
View File

@ -5,15 +5,7 @@ module Types
extend ActiveSupport::Concern
prepended do
mount_aliased_mutation 'AddAwardEmoji',
Mutations::AwardEmojis::Add,
deprecated: { reason: 'Use awardEmojiAdd', milestone: '13.2' }
mount_aliased_mutation 'RemoveAwardEmoji',
Mutations::AwardEmojis::Remove,
deprecated: { reason: 'Use awardEmojiRemove', milestone: '13.2' }
mount_aliased_mutation 'ToggleAwardEmoji',
Mutations::AwardEmojis::Toggle,
deprecated: { reason: 'Use awardEmojiToggle', milestone: '13.2' }
# placeholder for any FOSS mutations to be deprecated
end
end
end

6
app/graphql/types/packages/package_group_sort_enum.rb
View File

@ -6,10 +6,8 @@ module Types
graphql_name 'PackageGroupSort'
description 'Values for sorting group packages'
# The following enums are not available till we enable the new Arel node:
# See https://gitlab.com/gitlab-org/gitlab/-/merge_requests/58657#note_552632305
# value 'PROJECT_PATH_DESC', 'Project by descending order.', value: :project_path_desc
# value 'PROJECT_PATH_ASC', 'Project by ascending order.', value: :project_path_asc
value 'PROJECT_PATH_DESC', 'Ordered by project path in descending order.', value: :project_path_desc
value 'PROJECT_PATH_ASC', 'Ordered by project path in ascending order.', value: :project_path_asc
end
end
end

6
app/graphql/types/snippet_type.rb
View File

@ -61,12 +61,6 @@ module Types
description: 'Raw URL of the snippet.',
null: false
field :blob, type: Types::Snippets::BlobType,
description: 'Snippet blob.',
calls_gitaly: true,
null: false,
deprecated: { reason: 'Use `blobs`', milestone: '13.3' }
field :blobs, type: Types::Snippets::BlobType.connection_type,
description: 'Snippet blobs.',
calls_gitaly: true,

5
app/models/concerns/has_user_type.rb
View File

@ -12,10 +12,11 @@ module HasUserType
ghost: 5,
project_bot: 6,
migration_bot: 7,
security_bot: 8
security_bot: 8,
automation_bot: 9
}.with_indifferent_access.freeze
BOT_USER_TYPES = %w[alert_bot project_bot support_bot visual_review_bot migration_bot security_bot].freeze
BOT_USER_TYPES = %w[alert_bot project_bot support_bot visual_review_bot migration_bot security_bot automation_bot].freeze
NON_INTERNAL_USER_TYPES = %w[human project_bot service_user].freeze
INTERNAL_USER_TYPES = (USER_TYPES.keys - NON_INTERNAL_USER_TYPES).freeze

13
app/models/concerns/timebox.rb
View File

@ -44,7 +44,6 @@ module Timebox
validates :project, presence: true, unless: :group
validates :title, presence: true
validate :uniqueness_of_title, if: :title_changed?
validate :timebox_type_check
validate :start_date_should_be_less_than_due_date, if: proc { |m| m.start_date.present? && m.due_date.present? }
validate :dates_within_4_digits
@ -243,18 +242,6 @@ module Timebox
end
end
# Timebox titles must be unique across project and group timeboxes
def uniqueness_of_title
if project
relation = self.class.for_projects_and_groups([project_id], [project.group&.id])
elsif group
relation = self.class.for_projects_and_groups(group.projects.select(:id), [group.id])
end
title_exists = relation.find_by_title(title)
errors.add(:title, _("already being used for another group or project %{timebox_name}.") % { timebox_name: timebox_name }) if title_exists
end
# Timebox should be either a project timebox or a group timebox
def timebox_type_check
if group_id && project_id

12
app/models/concerns/token_authenticatable_strategies/encryption_helper.rb
View File

@ -5,10 +5,6 @@ module TokenAuthenticatableStrategies
DYNAMIC_NONCE_IDENTIFIER = "|"
NONCE_SIZE = 12
def self.encrypt_token(plaintext_token)
Gitlab::CryptoHelper.aes256_gcm_encrypt(plaintext_token)
end
def self.decrypt_token(token)
return unless token
@ -22,5 +18,13 @@ module TokenAuthenticatableStrategies
Gitlab::CryptoHelper.aes256_gcm_decrypt(token)
end
end
def self.encrypt_token(plaintext_token)
return Gitlab::CryptoHelper.aes256_gcm_encrypt(plaintext_token) unless Feature.enabled?(:dynamic_nonce, type: :ops)
iv = ::Digest::SHA256.hexdigest(plaintext_token).bytes.take(NONCE_SIZE).pack('c*')
token = Gitlab::CryptoHelper.aes256_gcm_encrypt(plaintext_token, nonce: iv)
"#{DYNAMIC_NONCE_IDENTIFIER}#{token}#{iv}"
end
end
end

13
app/models/milestone.rb
View File

@ -36,6 +36,7 @@ class Milestone < ApplicationRecord
scope :order_by_dates_and_title, -> { order(due_date: :asc, start_date: :asc, title: :asc) }
validates_associated :milestone_releases, message: -> (_, obj) { obj[:value].map(&:errors).map(&:full_messages).join(",") }
validate :uniqueness_of_title, if: :title_changed?
state_machine :state, initial: :active do
event :close do
@ -172,4 +173,16 @@ class Milestone < ApplicationRecord
def issues_finder_params
{ project_id: project_id, group_id: group_id, include_subgroups: group_id.present? }.compact
end
# milestone titles must be unique across project and group milestones
def uniqueness_of_title
if project
relation = self.class.for_projects_and_groups([project_id], [project.group&.id])
elsif group
relation = self.class.for_projects_and_groups(group.projects.select(:id), [group.id])
end
title_exists = relation.find_by_title(title)
errors.add(:title, _("already being used for another group or project %{timebox_name}.") % { timebox_name: timebox_name }) if title_exists
end
end

10
app/models/user.rb
View File

@ -782,6 +782,16 @@ class User < ApplicationRecord
end
end
def automation_bot
email_pattern = "automation%s@#{Settings.gitlab.host}"
unique_internal(where(user_type: :automation_bot), 'automation-bot', email_pattern) do |u|
u.bio = 'The GitLab automation bot used for automated workflows and tasks'
u.name = 'GitLab Automation Bot'
u.avatar = bot_avatar(image: 'support-bot.png') # todo: add an avatar for automation-bot
end
end
# Return true if there is only single non-internal user in the deployment,
# ghost user is ignored.
def single_user?

6
app/views/shared/runners/_runner_type_alert.html.haml
View File

@ -5,16 +5,16 @@
= s_('Runners|This runner is available to all groups and projects in your GitLab instance.')
.gl-alert-body
= s_('Runners|Shared runners are available to every project in a GitLab instance. If you want a runner to build only specific projects, restrict the project in the table below. After you restrict a runner to a project, you cannot change it back to a shared runner.')
= link_to _('Learn more.'), help_page_path('ci/runners/README', anchor: 'shared-runners'), target: '_blank', rel: 'noopener noreferrer'
= link_to _('Learn more.'), help_page_path('ci/runners/runners_scope', anchor: 'shared-runners'), target: '_blank', rel: 'noopener noreferrer'
- elsif runner.group_type?
%h4.gl-alert-title
= s_('Runners|This runner is available to all projects and subgroups in a group.')
.gl-alert-body
= s_('Runners|Use Group runners when you want all projects in a group to have access to a set of runners.')
= link_to _('Learn more.'), help_page_path('ci/runners/README', anchor: 'group-runners'), target: '_blank', rel: 'noopener noreferrer'
= link_to _('Learn more.'), help_page_path('ci/runners/runners_scope', anchor: 'group-runners'), target: '_blank', rel: 'noopener noreferrer'
- else
%h4.gl-alert-title
= s_('Runners|This runner is associated with specific projects.')
.gl-alert-body
= s_('Runners|You can set up a specific runner to be used by multiple projects but you cannot make this a shared runner.')
= link_to _('Learn more.'), help_page_path('ci/runners/README', anchor: 'specific-runners'), target: '_blank', rel: 'noopener noreferrer'
= link_to _('Learn more.'), help_page_path('ci/runners/runners_scope', anchor: 'specific-runners'), target: '_blank', rel: 'noopener noreferrer'

8
config/feature_flags/ops/dynamic_nonce.yml Normal file
View File

@ -0,0 +1,8 @@
---
name: dynamic_nonce
introduced_by_url:
rollout_issue_url:
milestone: '14.0'
type: ops
group: group::access
default_enabled: false

3
config/initializers/1_settings.rb
View File

@ -687,6 +687,9 @@ Gitlab.ee do
Settings.cron_jobs['iterations_update_status_worker'] ||= Settingslogic.new({})
Settings.cron_jobs['iterations_update_status_worker']['cron'] ||= '5 0 * * *'
Settings.cron_jobs['iterations_update_status_worker']['job_class'] = 'IterationsUpdateStatusWorker'
Settings.cron_jobs['iterations_generator_worker'] ||= Settingslogic.new({})
Settings.cron_jobs['iterations_generator_worker']['cron'] ||= '5 0 * * *'
Settings.cron_jobs['iterations_generator_worker']['job_class'] = 'Iterations::Cadences::ScheduleCreateIterationsWorker'
Settings.cron_jobs['vulnerability_statistics_schedule_worker'] ||= Settingslogic.new({})
Settings.cron_jobs['vulnerability_statistics_schedule_worker']['cron'] ||= '15 1 * * *'
Settings.cron_jobs['vulnerability_statistics_schedule_worker']['job_class'] = 'Vulnerabilities::Statistics::ScheduleWorker'

25
db/migrate/20210527065005_add_index_for_cadence_iterations_automation.rb Normal file
View File

@ -0,0 +1,25 @@
# frozen_string_literal: true
class AddIndexForCadenceIterationsAutomation < ActiveRecord::Migration[6.0]
include Gitlab::Database::MigrationHelpers
INDEX_NAME = 'cadence_create_iterations_automation'
disable_ddl_transaction!
def up
return if index_exists_by_name?(:iterations_cadences, INDEX_NAME)
execute(
<<-SQL
CREATE INDEX CONCURRENTLY #{INDEX_NAME} ON iterations_cadences
USING BTREE(automatic, duration_in_weeks, (DATE ((COALESCE("iterations_cadences"."last_run_date", DATE('01-01-1970')) + "iterations_cadences"."duration_in_weeks" * INTERVAL '1 week'))))
WHERE duration_in_weeks IS NOT NULL
SQL
)
end
def down
remove_concurrent_index_by_name :iterations_cadences, INDEX_NAME
end
end

20
db/migrate/20210529164247_change_iterations_title_uniqueness_index.rb Normal file
View File

@ -0,0 +1,20 @@
# frozen_string_literal: true
class ChangeIterationsTitleUniquenessIndex < ActiveRecord::Migration[6.0]
include Gitlab::Database::MigrationHelpers
INDEX_NAME = 'index_sprints_on_iterations_cadence_id_and_title'
OLD_INDEX_NAME = 'index_sprints_on_group_id_and_title'
disable_ddl_transaction!
def up
add_concurrent_index :sprints, [:iterations_cadence_id, :title], name: INDEX_NAME, unique: true
remove_concurrent_index_by_name :sprints, OLD_INDEX_NAME
end
def down
# noop
# rollback would not work as we can have duplicate records once the unique `index_sprints_on_group_id_and_title` index is removed
end
end

28
db/migrate/20210609013512_add_unique_index_for_batched_background_migrations.rb Normal file
View File

@ -0,0 +1,28 @@
# frozen_string_literal: true
class AddUniqueIndexForBatchedBackgroundMigrations < ActiveRecord::Migration[6.1]
include Gitlab::Database::MigrationHelpers
disable_ddl_transaction!
TABLE_NAME = :batched_background_migrations
INDEX_NAME = 'index_batched_background_migrations_on_unique_configuration'
REDUNDANT_INDEX_NAME = 'index_batched_migrations_on_job_table_and_column_name'
def up
add_concurrent_index TABLE_NAME,
%i[job_class_name table_name column_name job_arguments],
unique: true,
name: INDEX_NAME
remove_concurrent_index_by_name TABLE_NAME, REDUNDANT_INDEX_NAME
end
def down
add_concurrent_index TABLE_NAME,
%i[job_class_name table_name column_name],
name: REDUNDANT_INDEX_NAME
remove_concurrent_index_by_name TABLE_NAME, INDEX_NAME
end
end

21
db/post_migrate/20210604070207_retry_backfill_traversal_ids.rb Normal file
View File

@ -0,0 +1,21 @@
# frozen_string_literal: true
class RetryBackfillTraversalIds < ActiveRecord::Migration[6.1]
include Gitlab::Database::MigrationHelpers
ROOTS_MIGRATION = 'BackfillNamespaceTraversalIdsRoots'
CHILDREN_MIGRATION = 'BackfillNamespaceTraversalIdsChildren'
DOWNTIME = false
DELAY_INTERVAL = 2.minutes
disable_ddl_transaction!
def up
duration = requeue_background_migration_jobs_by_range_at_intervals(ROOTS_MIGRATION, DELAY_INTERVAL)
requeue_background_migration_jobs_by_range_at_intervals(CHILDREN_MIGRATION, DELAY_INTERVAL, initial_delay: duration)
end
def down
# no-op
end
end

1
db/schema_migrations/20210527065005 Normal file
View File

@ -0,0 +1 @@
983b736defaa128f7466a784d2a06de293fa6b1cee76121e533e7966d19aad73

1
db/schema_migrations/20210529164247 Normal file
View File

@ -0,0 +1 @@
8aa9e00be5f2bc6076f4a42a479aff4318b9e4d3da48798117fec67df7158db4

1
db/schema_migrations/20210604070207 Normal file
View File

@ -0,0 +1 @@
ec44b7f134de2ea6537c6fe3109fa9d7e32785233f3d1b8e9ea118474d21526a

1
db/schema_migrations/20210609013512 Normal file
View File

@ -0,0 +1 @@
ddd40d4fb063b3a728f4b9a214d6033f70ee3719ac769957f5295a0c5f62a5c0

8
db/structure.sql
View File

@ -22305,6 +22305,8 @@ CREATE INDEX approval_mr_rule_index_merge_request_id ON approval_merge_request_r
CREATE UNIQUE INDEX bulk_import_trackers_uniq_relation_by_entity ON bulk_import_trackers USING btree (bulk_import_entity_id, relation);
CREATE INDEX cadence_create_iterations_automation ON iterations_cadences USING btree (automatic, duration_in_weeks, date((COALESCE(last_run_date, '1970-01-01'::date) + ((duration_in_weeks)::double precision * '7 days'::interval)))) WHERE (duration_in_weeks IS NOT NULL);
CREATE INDEX ci_builds_gitlab_monitor_metrics ON ci_builds USING btree (status, created_at, project_id) WHERE ((type)::text = 'Ci::Build'::text);
CREATE INDEX code_owner_approval_required ON protected_branches USING btree (project_id, code_owner_approval_required) WHERE (code_owner_approval_required = true);
@ -22611,12 +22613,12 @@ CREATE INDEX index_badges_on_group_id ON badges USING btree (group_id);
CREATE INDEX index_badges_on_project_id ON badges USING btree (project_id);
CREATE UNIQUE INDEX index_batched_background_migrations_on_unique_configuration ON batched_background_migrations USING btree (job_class_name, table_name, column_name, job_arguments);
CREATE INDEX index_batched_jobs_by_batched_migration_id_and_id ON batched_background_migration_jobs USING btree (batched_background_migration_id, id);
CREATE INDEX index_batched_jobs_on_batched_migration_id_and_status ON batched_background_migration_jobs USING btree (batched_background_migration_id, status);
CREATE INDEX index_batched_migrations_on_job_table_and_column_name ON batched_background_migrations USING btree (job_class_name, table_name, column_name);
CREATE INDEX index_board_assignees_on_assignee_id ON board_assignees USING btree (assignee_id);
CREATE UNIQUE INDEX index_board_assignees_on_board_id_and_assignee_id ON board_assignees USING btree (board_id, assignee_id);
@ -24647,7 +24649,7 @@ CREATE INDEX index_sprints_on_due_date ON sprints USING btree (due_date);
CREATE INDEX index_sprints_on_group_id ON sprints USING btree (group_id);
CREATE UNIQUE INDEX index_sprints_on_group_id_and_title ON sprints USING btree (group_id, title) WHERE (group_id IS NOT NULL);
CREATE UNIQUE INDEX index_sprints_on_iterations_cadence_id_and_title ON sprints USING btree (iterations_cadence_id, title);
CREATE UNIQUE INDEX index_sprints_on_project_id_and_iid ON sprints USING btree (project_id, iid);

13
doc/administration/database_load_balancing.md
View File

@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Database Load Balancing **(FREE SELF)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/1283) in [GitLab Premium](https://about.gitlab.com/pricing/) 9.0.
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60894) from GitLab Premium to GitLab Free in 14.0. See the [instructions below](#load-balancing-in-gitlab).
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60894) from GitLab Premium to GitLab Free in 14.0.
Distribute read-only queries among multiple database servers.
@ -104,17 +104,6 @@ the following. This will balance the load between `host1.example.com` and
1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
### Load balancing in GitLab Free
Database load balancing was moved from GitLab Premium to GitLab Free in
14.0 with some [known limitations](https://gitlab.com/gitlab-org/gitlab/-/issues/327902).
For example, requesting new jobs for runners may fail. Hence, this feature is **not ready for production use** in GitLab Free.
To use database load balancing in GitLab Free, set the `ENABLE_LOAD_BALANCING_FOR_FOSS`
[environment
variable](https://docs.gitlab.com/omnibus/settings/environment-variables.html)
to `true`.
### Enable the load balancer for Sidekiq
Sidekiq mostly writes to the database, which means that most of its traffic hits the

2
doc/administration/index.md
View File

@ -172,7 +172,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
- [External Pipeline Validation](external_pipeline_validation.md): Enable, disable, and configure external pipeline validation.
- [Job artifacts](job_artifacts.md): Enable, disable, and configure job artifacts (a set of files and directories which are outputted by a job when it completes successfully).
- [Job logs](job_logs.md): Information about the job logs.
- [Register runners](../ci/runners/README.md#types-of-runners): Learn how to register and configure runners.
- [Register runners](../ci/runners/runners_scope.md): Learn how to register and configure runners.
- [Shared runners pipelines quota](../user/admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota): Limit the usage of pipeline minutes for shared runners.
- [Enable/disable Auto DevOps](../topics/autodevops/index.md#enable-or-disable-auto-devops): Enable or disable Auto DevOps for your instance.

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

@ -411,11 +411,6 @@ The following IPs will be used as an example:
- `10.6.0.12`: Consul 2
- `10.6.0.13`: Consul 3
NOTE:
The configuration processes for the other servers in your reference architecture will
use the `/etc/gitlab/gitlab-secrets.json` file from your Consul server to connect
with the other servers.
To configure Consul:
1. SSH in to the server that will host Consul.
@ -446,7 +441,11 @@ To configure Consul:
gitlab_rails['auto_migrate'] = false
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Go through the steps again for all the other Consul nodes, and
make sure you set up the correct IPs.
@ -603,9 +602,8 @@ PostgreSQL, with Patroni managing its failover, will default to use `pg_rewind`
Like most failover handling methods, this has a small chance of leading to data loss.
Learn more about the various [Patroni replication methods](../postgresql/replication_and_failover.md#selecting-the-appropriate-patroni-replication-method).
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
@ -705,9 +703,8 @@ The following IPs will be used as an example:
node_exporter['listen_address'] = '0.0.0.0:9100'
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
@ -866,9 +863,8 @@ a node and change its status from primary to replica (and vice versa).
gitlab_rails['auto_migrate'] = false
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
@ -933,9 +929,8 @@ You can specify multiple roles, like sentinel and Redis, as:
gitlab_rails['auto_migrate'] = false
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Go through the steps again for all the other replica nodes, and
@ -1065,9 +1060,8 @@ To configure the Sentinel Cache server:
gitlab_rails['auto_migrate'] = false
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Go through the steps again for all the other Consul/Sentinel nodes, and
@ -1131,9 +1125,8 @@ a node and change its status from primary to replica (and vice versa).
gitlab_rails['auto_migrate'] = false
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
@ -1192,9 +1185,8 @@ You can specify multiple roles, like sentinel and Redis, as:
gitlab_rails['auto_migrate'] = false
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Go through the steps again for all the other replica nodes, and
@ -1324,17 +1316,8 @@ To configure the Sentinel Queues server:
gitlab_rails['auto_migrate'] = false
```
1. To prevent database migrations from running on upgrade, run:
```shell
sudo touch /etc/gitlab/skip-auto-reconfigure
```
Only the primary GitLab application server should handle migrations.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Go through the steps again for all the other Sentinel nodes, and
@ -1435,7 +1418,11 @@ in the second step, do not supply the `EXTERNAL_URL` value.
# END user configuration
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Follow the [post configuration](#praefect-postgresql-post-configuration).
<div align="right">
@ -1533,18 +1520,18 @@ To configure the Praefect nodes, on each one:
1. Edit the `/etc/gitlab/gitlab.rb` file to configure Praefect:
```ruby
# Avoid running unnecessary services on the Gitaly server
# Avoid running unnecessary services on the Praefect server
gitaly['enable'] = false
postgresql['enable'] = false
redis['enable'] = false
nginx['enable'] = false
puma['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
grafana['enable'] = false
# If you run a separate monitoring node you can disable these services
alertmanager['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
grafana['enable'] = false
gitlab_exporter['enable'] = false
nginx['enable'] = false
# Praefect Configuration
praefect['enable'] = true
@ -1612,11 +1599,25 @@ To configure the Praefect nodes, on each one:
# END user configuration
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and
then replace the file of the same name on this server. If that file isn't on
this server, add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. Praefect requires to run some database migrations, much like the main GitLab application. For this
you should select **one Praefect node only to run the migrations**, AKA the _Deploy Node_. This node
must be configured first before the others as follows:
1. In the `/etc/gitlab/gitlab.rb` file, change the `praefect['auto_migrate']` setting value from `false` to `true`
1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
```shell
sudo touch /etc/gitlab/skip-auto-reconfigure
```
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect and
to run the Praefect database migrations.
1. On all other Praefect nodes, [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
### Configure Gitaly
@ -1660,20 +1661,17 @@ On each node:
storage paths, enable the network listener, and to configure the token:
```ruby
# /etc/gitlab/gitlab.rb
# Avoid running unnecessary services on the Gitaly server
postgresql['enable'] = false
redis['enable'] = false
nginx['enable'] = false
puma['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
grafana['enable'] = false
# If you run a separate monitoring node you can disable these services
alertmanager['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
grafana['enable'] = false
gitlab_exporter['enable'] = false
nginx['enable'] = false
# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false
@ -1681,9 +1679,11 @@ On each node:
# Configure the gitlab-shell API callback URL. Without this, `git push` will
# fail. This can be your 'front door' GitLab URL or an internal load
# balancer.
# Don't forget to copy `/etc/gitlab/gitlab-secrets.json` from web server to Gitaly server.
gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
# Gitaly
gitaly['enable'] = true
# Make Gitaly accept connections on all network interfaces. You must use
# firewalls to restrict access to this address/port.
# Comment out following line if you only want to support TLS connections
@ -1725,9 +1725,8 @@ On each node:
})
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and
then replace the file of the same name on this server. If that file isn't on
this server, add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
@ -1834,28 +1833,19 @@ To configure the Sidekiq nodes, on each one:
1. Open `/etc/gitlab/gitlab.rb` with your editor:
```ruby
########################################
##### Services Disabled ###
########################################
nginx['enable'] = false
grafana['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
# Avoid running unnecessary services on the Sidekiq server
gitaly['enable'] = false
gitlab_workhorse['enable'] = false
nginx['enable'] = false
puma['enable'] = false
postgres_exporter['enable'] = false
postgresql['enable'] = false
redis['enable'] = false
redis_exporter['enable'] = false
puma['enable'] = false
gitlab_workhorse['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
grafana['enable'] = false
gitlab_exporter['enable'] = false
nginx['enable'] = false
########################################
#### Redis ###
########################################
# Redis
## Redis connection details
## First cluster that will host the cache
gitlab_rails['redis_cache_instance'] = 'redis://:<REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER>@gitlab-redis-cache'
@ -1887,13 +1877,10 @@ To configure the Sidekiq nodes, on each one:
{host: '10.6.0.83', port: 26379},
]
#######################################
### Gitaly ###
#######################################
# git_data_dirs get configured for the Praefect virtual storage
# Address is Internal Load Balancer for Praefect
# Token is praefect_external_token
# Gitaly Cluster
## git_data_dirs get configured for the Praefect virtual storage
## Address is Internal Load Balancer for Praefect
## Token is praefect_external_token
git_data_dirs({
"default" => {
"gitaly_address" => "tcp://10.6.0.40:2305", # internal load balancer IP
@ -1901,20 +1888,17 @@ To configure the Sidekiq nodes, on each one:
}
})
#######################################
### Postgres ###
#######################################
# PostgreSQL
gitlab_rails['db_host'] = '10.6.0.40' # internal load balancer IP
gitlab_rails['db_port'] = 6432
gitlab_rails['db_password'] = '<postgresql_user_password>'
gitlab_rails['db_adapter'] = 'postgresql'
gitlab_rails['db_encoding'] = 'unicode'
# Prevent database migrations from running on upgrade automatically
## Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false
#######################################
### Sidekiq configuration ###
#######################################
# Sidekiq
sidekiqp['enable'] = true
sidekiq['listen_address'] = "0.0.0.0"
# Set number of Sidekiq queue processes to the same number as available CPUs
@ -1923,9 +1907,7 @@ To configure the Sidekiq nodes, on each one:
# Set number of Sidekiq threads per queue process to the recommend number of 10
sidekiq['max_concurrency'] = 10
#######################################
### Monitoring configuration ###
#######################################
# Monitoring
consul['enable'] = true
consul['monitoring_service_discovery'] = true
@ -1933,18 +1915,15 @@ To configure the Sidekiq nodes, on each one:
retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}
# Set the network addresses that the exporters will listen on
## Set the network addresses that the exporters will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'
# Rails Status for prometheus
## Add the monitoring node's IP address to the monitoring whitelist
gitlab_rails['monitoring_whitelist'] = ['10.6.0.151/32', '127.0.0.0/8']
#############################
### Object storage ###
#############################
# This is an example for configuring Object Storage on GCP
# Replace this config with your chosen Object Storage provider as desired
# Object Storage
## This is an example for configuring Object Storage on GCP
## Replace this config with your chosen Object Storage provider as desired
gitlab_rails['object_store']['connection'] = {
'provider' => 'Google',
'google_project' => '<gcp-project-name>',
@ -1957,11 +1936,26 @@ To configure the Sidekiq nodes, on each one:
gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
gitlab_rails['backup_upload_connection'] = {
'provider' => 'Google',
'google_project' => '<gcp-project-name>',
'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
```shell
sudo touch /etc/gitlab/skip-auto-reconfigure
```
Only a single designated node should handle migrations as detailed in the
[GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
@ -1992,9 +1986,6 @@ On each node perform the following:
1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
package of your choice. Be sure to follow _only_ installation steps 1 and 2
on the page.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Edit `/etc/gitlab/gitlab.rb` and use the following configuration.
To maintain uniformity of links across nodes, the `external_url`
@ -2089,9 +2080,15 @@ On each node perform the following:
gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
gitlab_rails['backup_upload_connection'] = {
'provider' => 'Google',
'google_project' => '<gcp-project-name>',
'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
```
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. If you're using [Gitaly with TLS support](#gitaly-cluster-tls-support), make sure the
`git_data_dirs` entry is configured with `tls` instead of `tcp`:
@ -2110,6 +2107,20 @@ On each node perform the following:
sudo cp cert.pem /etc/gitlab/trusted-certs/
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
```shell
sudo touch /etc/gitlab/skip-auto-reconfigure
```
Only a single designated node should handle migrations as detailed in the
[GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. If you're [using NFS](#configure-nfs-optional):
1. If necessary, install the NFS client utility packages using the following
commands:
@ -2149,7 +2160,8 @@ On each node perform the following:
registry['gid'] = 9002
```
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. Confirm the node can connect to Gitaly:
```shell
@ -2213,28 +2225,20 @@ To configure the Monitoring node:
1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
package of your choice. Be sure to follow _only_ installation steps 1 and 2
on the page.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
```ruby
external_url 'http://gitlab.example.com'
# Disable all other services
alertmanager['enable'] = false
# Avoid running unnecessary services on the Prometheus server
gitaly['enable'] = false
gitlab_exporter['enable'] = false
gitlab_workhorse['enable'] = false
nginx['enable'] = true
postgres_exporter['enable'] = false
postgresql['enable'] = false
redis['enable'] = false
redis_exporter['enable'] = false
sidekiq['enable'] = false
puma['enable'] = false
node_exporter['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
alertmanager['enable'] = false
gitlab_exporter['enable'] = false
# Enable Prometheus
@ -2260,7 +2264,8 @@ To configure the Monitoring node:
gitlab_rails['auto_migrate'] = false
```
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. In the GitLab UI, set `admin/application_settings/metrics_and_profiling` > Metrics - Grafana to `/-/grafana` to
`http[s]://<MONITOR NODE>/-/grafana`
@ -2395,7 +2400,7 @@ future with further specific cloud provider details.
| Service | Nodes | Configuration | GCP | Allocatable CPUs and Memory |
|-------------------------------------------------------|-------|-------------------------|------------------|-----------------------------|
| Webservice | 4 | 32 vCPU, 28.8 GB memory | `n1-standard-32` | 127.5 vCPU, 118 GB memory |
| Webservice | 4 | 32 vCPU, 28.8 GB memory | `n1-highcpu-32` | 127.5 vCPU, 118 GB memory |
| Sidekiq | 4 | 4 vCPU, 15 GB memory | `n1-standard-4` | 15.5 vCPU, 50 GB memory |
| Supporting services such as NGINX, Prometheus, etc... | 2 | 4 vCPU, 15 GB memory | `n1-standard-4` | 7.75 vCPU, 25 GB memory |

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

@ -413,11 +413,6 @@ The following IPs will be used as an example:
- `10.6.0.12`: Consul 2
- `10.6.0.13`: Consul 3
NOTE:
The configuration processes for the other servers in your reference architecture will
use the `/etc/gitlab/gitlab-secrets.json` file from your Consul server to connect
with the other servers.
To configure Consul:
1. SSH in to the server that will host Consul.
@ -448,7 +443,11 @@ To configure Consul:
gitlab_rails['auto_migrate'] = false
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Go through the steps again for all the other Consul nodes, and
make sure you set up the correct IPs.
@ -605,9 +604,8 @@ PostgreSQL, with Patroni managing its failover, will default to use `pg_rewind`
Like most failover handling methods, this has a small chance of leading to data loss.
Learn more about the various [Patroni replication methods](../postgresql/replication_and_failover.md#selecting-the-appropriate-patroni-replication-method).
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
@ -707,9 +705,8 @@ The following IPs will be used as an example:
node_exporter['listen_address'] = '0.0.0.0:9100'
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
@ -868,9 +865,8 @@ a node and change its status from primary to replica (and vice versa).
gitlab_rails['auto_migrate'] = false
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
@ -935,11 +931,11 @@ You can specify multiple roles, like sentinel and Redis, as:
gitlab_rails['auto_migrate'] = false
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Go through the steps again for all the other replica nodes, and
make sure to set up the IPs correctly.
@ -1067,11 +1063,11 @@ To configure the Sentinel Cache server:
gitlab_rails['auto_migrate'] = false
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Go through the steps again for all the other Consul/Sentinel nodes, and
make sure you set up the correct IPs.
@ -1133,9 +1129,8 @@ a node and change its status from primary to replica (and vice versa).
gitlab_rails['auto_migrate'] = false
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
@ -1194,11 +1189,11 @@ You can specify multiple roles, like sentinel and Redis, as:
gitlab_rails['auto_migrate'] = false
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Go through the steps again for all the other replica nodes, and
make sure to set up the IPs correctly.
@ -1326,7 +1321,10 @@ To configure the Sentinel Queues server:
gitlab_rails['auto_migrate'] = false
```
1. To prevent database migrations from running on upgrade, run:
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
```shell
sudo touch /etc/gitlab/skip-auto-reconfigure
@ -1334,11 +1332,8 @@ To configure the Sentinel Queues server:
Only the primary GitLab application server should handle migrations.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Go through the steps again for all the other Sentinel nodes, and
make sure you set up the correct IPs.
@ -1437,7 +1432,11 @@ in the second step, do not supply the `EXTERNAL_URL` value.
# END user configuration
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Follow the [post configuration](#praefect-postgresql-post-configuration).
<div align="right">
@ -1535,18 +1534,18 @@ To configure the Praefect nodes, on each one:
1. Edit the `/etc/gitlab/gitlab.rb` file to configure Praefect:
```ruby
# Avoid running unnecessary services on the Gitaly server
# Avoid running unnecessary services on the Praefect server
gitaly['enable'] = false
postgresql['enable'] = false
redis['enable'] = false
nginx['enable'] = false
puma['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
grafana['enable'] = false
# If you run a separate monitoring node you can disable these services
alertmanager['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
grafana['enable'] = false
gitlab_exporter['enable'] = false
nginx['enable'] = false
# Praefect Configuration
praefect['enable'] = true
@ -1614,11 +1613,25 @@ To configure the Praefect nodes, on each one:
# END user configuration
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and
then replace the file of the same name on this server. If that file isn't on
this server, add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. Praefect requires to run some database migrations, much like the main GitLab application. For this
you should select **one Praefect node only to run the migrations**, AKA the _Deploy Node_. This node
must be configured first before the others as follows:
1. In the `/etc/gitlab/gitlab.rb` file, change the `praefect['auto_migrate']` setting value from `false` to `true`
1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
```shell
sudo touch /etc/gitlab/skip-auto-reconfigure
```
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect and
to run the Praefect database migrations.
1. On all other Praefect nodes, [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
### Configure Gitaly
@ -1662,20 +1675,17 @@ On each node:
storage paths, enable the network listener, and to configure the token:
```ruby
# /etc/gitlab/gitlab.rb
# Avoid running unnecessary services on the Gitaly server
postgresql['enable'] = false
redis['enable'] = false
nginx['enable'] = false
puma['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
grafana['enable'] = false
# If you run a separate monitoring node you can disable these services
alertmanager['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
grafana['enable'] = false
gitlab_exporter['enable'] = false
nginx['enable'] = false
# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false
@ -1683,9 +1693,11 @@ On each node:
# Configure the gitlab-shell API callback URL. Without this, `git push` will
# fail. This can be your 'front door' GitLab URL or an internal load
# balancer.
# Don't forget to copy `/etc/gitlab/gitlab-secrets.json` from web server to Gitaly server.
gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
# Gitaly
gitaly['enable'] = true
# Make Gitaly accept connections on all network interfaces. You must use
# firewalls to restrict access to this address/port.
# Comment out following line if you only want to support TLS connections
@ -1727,9 +1739,8 @@ On each node:
})
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and
then replace the file of the same name on this server. If that file isn't on
this server, add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
@ -1836,28 +1847,19 @@ To configure the Sidekiq nodes, on each one:
1. Open `/etc/gitlab/gitlab.rb` with your editor:
```ruby
########################################
##### Services Disabled ###
########################################
nginx['enable'] = false
grafana['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
# Avoid running unnecessary services on the Sidekiq server
gitaly['enable'] = false
gitlab_workhorse['enable'] = false
nginx['enable'] = false
puma['enable'] = false
postgres_exporter['enable'] = false
postgresql['enable'] = false
redis['enable'] = false
redis_exporter['enable'] = false
puma['enable'] = false
gitlab_workhorse['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
grafana['enable'] = false
gitlab_exporter['enable'] = false
nginx['enable'] = false
########################################
#### Redis ###
########################################
# Redis
## Redis connection details
## First cluster that will host the cache
gitlab_rails['redis_cache_instance'] = 'redis://:<REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER>@gitlab-redis-cache'
@ -1889,13 +1891,10 @@ To configure the Sidekiq nodes, on each one:
{host: '10.6.0.83', port: 26379},
]
#######################################
### Gitaly ###
#######################################
# git_data_dirs get configured for the Praefect virtual storage
# Address is Internal Load Balancer for Praefect
# Token is praefect_external_token
# Gitaly Cluster
## git_data_dirs get configured for the Praefect virtual storage
## Address is Internal Load Balancer for Praefect
## Token is praefect_external_token
git_data_dirs({
"default" => {
"gitaly_address" => "tcp://10.6.0.40:2305", # internal load balancer IP
@ -1903,20 +1902,17 @@ To configure the Sidekiq nodes, on each one:
}
})
#######################################
### Postgres ###
#######################################
# PostgreSQL
gitlab_rails['db_host'] = '10.6.0.20' # internal load balancer IP
gitlab_rails['db_port'] = 6432
gitlab_rails['db_password'] = '<postgresql_user_password>'
gitlab_rails['db_adapter'] = 'postgresql'
gitlab_rails['db_encoding'] = 'unicode'
# Prevent database migrations from running on upgrade automatically
## Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false
#######################################
### Sidekiq configuration ###
#######################################
# Sidekiq
sidekiq['enable'] = true
sidekiq['listen_address'] = "0.0.0.0"
# Set number of Sidekiq queue processes to the same number as available CPUs
@ -1925,9 +1921,7 @@ To configure the Sidekiq nodes, on each one:
# Set number of Sidekiq threads per queue process to the recommend number of 10
sidekiq['max_concurrency'] = 10
#######################################
### Monitoring configuration ###
#######################################
# Monitoring
consul['enable'] = true
consul['monitoring_service_discovery'] = true
@ -1935,16 +1929,13 @@ To configure the Sidekiq nodes, on each one:
retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}
# Set the network addresses that the exporters will listen on
## Set the network addresses that the exporters will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'
# Rails Status for prometheus
## Add the monitoring node's IP address to the monitoring whitelist
gitlab_rails['monitoring_whitelist'] = ['10.6.0.151/32', '127.0.0.0/8']
#############################
### Object storage ###
#############################
# Object Storage
# This is an example for configuring Object Storage on GCP
# Replace this config with your chosen Object Storage provider as desired
gitlab_rails['object_store']['connection'] = {
@ -1959,11 +1950,26 @@ To configure the Sidekiq nodes, on each one:
gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
gitlab_rails['backup_upload_connection'] = {
'provider' => 'Google',
'google_project' => '<gcp-project-name>',
'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
```shell
sudo touch /etc/gitlab/skip-auto-reconfigure
```
Only a single designated node should handle migrations as detailed in the
[GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
@ -1996,9 +2002,6 @@ On each node perform the following:
1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
package of your choice. Be sure to follow _only_ installation steps 1 and 2
on the page.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Edit `/etc/gitlab/gitlab.rb` and use the following configuration.
To maintain uniformity of links across nodes, the `external_url`
@ -2093,9 +2096,15 @@ On each node perform the following:
gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
gitlab_rails['backup_upload_connection'] = {
'provider' => 'Google',
'google_project' => '<gcp-project-name>',
'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
```
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. If you're using [Gitaly with TLS support](#gitaly-cluster-tls-support), make sure the
`git_data_dirs` entry is configured with `tls` instead of `tcp`:
@ -2114,6 +2123,20 @@ On each node perform the following:
sudo cp cert.pem /etc/gitlab/trusted-certs/
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
```shell
sudo touch /etc/gitlab/skip-auto-reconfigure
```
Only a single designated node should handle migrations as detailed in the
[GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. If you're [using NFS](#configure-nfs-optional):
1. If necessary, install the NFS client utility packages using the following
commands:
@ -2153,7 +2176,7 @@ On each node perform the following:
registry['gid'] = 9002
```
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. Confirm the node can connect to Gitaly:
```shell
@ -2217,28 +2240,20 @@ To configure the Monitoring node:
1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
package of your choice. Be sure to follow _only_ installation steps 1 and 2
on the page.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
```ruby
external_url 'http://gitlab.example.com'
# Disable all other services
alertmanager['enable'] = false
# Avoid running unnecessary services on the Prometheus server
gitaly['enable'] = false
gitlab_exporter['enable'] = false
gitlab_workhorse['enable'] = false
nginx['enable'] = true
postgres_exporter['enable'] = false
postgresql['enable'] = false
redis['enable'] = false
redis_exporter['enable'] = false
sidekiq['enable'] = false
puma['enable'] = false
node_exporter['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
alertmanager['enable'] = false
gitlab_exporter['enable'] = false
# Enable Prometheus

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

@ -295,6 +295,9 @@ further configuration steps.
gitlab_rails['auto_migrate'] = false
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Note the PostgreSQL node's IP address or hostname, port, and
plain text password. These will be necessary when configuring the [GitLab
@ -347,18 +350,17 @@ Omnibus:
## Enable Redis
redis['enable'] = true
## Disable all other services
# Avoid running unnecessary services on the Redis server
gitaly['enable'] = false
postgresql['enable'] = false
puma['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
puma['enable'] = false
postgresql['enable'] = false
nginx['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
pgbouncer_exporter['enable'] = false
gitlab_exporter['enable'] = false
gitaly['enable'] = false
grafana['enable'] = false
gitlab_exporter['enable'] = false
nginx['enable'] = false
redis['bind'] = '0.0.0.0'
redis['port'] = 6379
@ -375,7 +377,11 @@ Omnibus:
}
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Note the Redis node's IP address or hostname, port, and
Redis password. These will be necessary when [configuring the GitLab
application servers](#configure-gitlab-rails) later.
@ -454,15 +460,14 @@ To configure the Gitaly server, on the server node you want to use for Gitaly:
# Avoid running unnecessary services on the Gitaly server
postgresql['enable'] = false
redis['enable'] = false
nginx['enable'] = false
puma['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
grafana['enable'] = false
# If you run a separate monitoring node you can disable these services
alertmanager['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
grafana['enable'] = false
gitlab_exporter['enable'] = false
nginx['enable'] = false
# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false
@ -470,9 +475,11 @@ To configure the Gitaly server, on the server node you want to use for Gitaly:
# Configure the gitlab-shell API callback URL. Without this, `git push` will
# fail. This can be your 'front door' GitLab URL or an internal load
# balancer.
# Don't forget to copy `/etc/gitlab/gitlab-secrets.json` from web server to Gitaly server.
gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
# Gitaly
gitaly['enable'] = true
# Make Gitaly accept connections on all network interfaces. You must use
# firewalls to restrict access to this address/port.
# Comment out following line if you only want to support TLS connections
@ -492,7 +499,11 @@ To configure the Gitaly server, on the server node you want to use for Gitaly:
})
```
1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Confirm that Gitaly can perform callbacks to the internal API:
```shell
@ -656,10 +667,7 @@ On each node perform the following:
gitlab_rails['monitoring_whitelist'] = ['<MONITOR NODE IP>/32', '127.0.0.0/8']
nginx['status']['options']['allow'] = ['<MONITOR NODE IP>/32', '127.0.0.0/8']
#############################
### Object storage ###
#############################
# Object Storage
# This is an example for configuring Object Storage on GCP
# Replace this config with your chosen Object Storage provider as desired
gitlab_rails['object_store']['connection'] = {
@ -675,6 +683,13 @@ On each node perform the following:
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
gitlab_rails['backup_upload_connection'] = {
'provider' => 'Google',
'google_project' => '<gcp-project-name>',
'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
## Uncomment and edit the following options if you have set up NFS
##
## Prevent GitLab from starting if NFS data mounts are not available
@ -708,7 +723,20 @@ On each node perform the following:
sudo cp cert.pem /etc/gitlab/trusted-certs/
```
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
```shell
sudo touch /etc/gitlab/skip-auto-reconfigure
```
Only a single designated node should handle migrations as detailed in the
[GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Run `sudo gitlab-rake gitlab:gitaly:check` to confirm the node can connect to Gitaly.
1. Tail the logs to see the requests:
@ -716,11 +744,6 @@ On each node perform the following:
sudo gitlab-ctl tail gitaly
```
1. Save the `/etc/gitlab/gitlab-secrets.json` file from one of the two
application nodes and install it on the other application node and the
[Gitaly node](#configure-gitaly) and
[reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
When you specify `https` in the `external_url`, as in the previous example,
GitLab expects that the SSL certificates are in `/etc/gitlab/ssl/`. If the
certificates aren't present, NGINX will fail to start. For more information, see
@ -777,19 +800,14 @@ running [Prometheus](../monitoring/prometheus/index.md) and
grafana['enable'] = true
grafana['admin_password'] = 'toomanysecrets'
# Disable all other services
alertmanager['enable'] = false
# Avoid running unnecessary services on the Prometheus server
gitaly['enable'] = false
gitlab_exporter['enable'] = false
gitlab_workhorse['enable'] = false
nginx['enable'] = true
postgres_exporter['enable'] = false
postgresql['enable'] = false
redis['enable'] = false
redis_exporter['enable'] = false
sidekiq['enable'] = false
puma['enable'] = false
node_exporter['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
alertmanager['enable'] = false
gitlab_exporter['enable'] = false
# Prevent database migrations from running on upgrade automatically

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

@ -508,6 +508,9 @@ a node and change its status from primary to replica (and vice versa).
gitlab_rails['auto_migrate'] = false
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
You can specify multiple roles, like sentinel and Redis, as:
@ -591,6 +594,9 @@ run: redis-exporter: (pid 30075) 76861s; run: log: (pid 29674) 76896s
gitlab_rails['auto_migrate'] = false
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Go through the steps again for all the other replica nodes, and
make sure to set up the IPs correctly.
@ -720,7 +726,11 @@ To configure the Sentinel:
gitlab_rails['auto_migrate'] = false
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Go through the steps again for all the other Consul/Sentinel nodes, and
make sure you set up the correct IPs.
@ -878,9 +888,8 @@ PostgreSQL, with Patroni managing its failover, will default to use `pg_rewind`
Like most failover handling methods, this has a small chance of leading to data loss.
Learn more about the various [Patroni replication methods](../postgresql/replication_and_failover.md#selecting-the-appropriate-patroni-replication-method).
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
@ -982,6 +991,9 @@ The following IPs will be used as an example:
pgbouncer_exporter['listen_address'] = '0.0.0.0:9188'
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Create a `.pgpass` file so Consul is able to
@ -1135,6 +1147,9 @@ in the second step, do not supply the `EXTERNAL_URL` value.
# END user configuration
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Follow the [post configuration](#praefect-postgresql-post-configuration).
@ -1233,18 +1248,18 @@ To configure the Praefect nodes, on each one:
1. Edit the `/etc/gitlab/gitlab.rb` file to configure Praefect:
```ruby
# Avoid running unnecessary services on the Gitaly server
# Avoid running unnecessary services on the Praefect server
gitaly['enable'] = false
postgresql['enable'] = false
redis['enable'] = false
nginx['enable'] = false
puma['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
grafana['enable'] = false
# If you run a separate monitoring node you can disable these services
alertmanager['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
grafana['enable'] = false
gitlab_exporter['enable'] = false
nginx['enable'] = false
# Praefect Configuration
praefect['enable'] = true
@ -1312,11 +1327,25 @@ To configure the Praefect nodes, on each one:
# END user configuration
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and
then replace the file of the same name on this server. If that file isn't on
this server, add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. Praefect requires to run some database migrations, much like the main GitLab application. For this
you should select **one Praefect node only to run the migrations**, AKA the _Deploy Node_. This node
must be configured first before the others as follows:
1. In the `/etc/gitlab/gitlab.rb` file, change the `praefect['auto_migrate']` setting value from `false` to `true`
1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
```shell
sudo touch /etc/gitlab/skip-auto-reconfigure
```
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect and
to run the Praefect database migrations.
1. On all other Praefect nodes, [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
### Configure Gitaly
@ -1360,28 +1389,27 @@ On each node:
storage paths, enable the network listener, and to configure the token:
```ruby
# /etc/gitlab/gitlab.rb
# Avoid running unnecessary services on the Gitaly server
postgresql['enable'] = false
redis['enable'] = false
nginx['enable'] = false
puma['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
grafana['enable'] = false
# If you run a separate monitoring node you can disable these services
alertmanager['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
grafana['enable'] = false
gitlab_exporter['enable'] = false
nginx['enable'] = false
# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false
# Gitaly
gitaly['enable'] = true
# Configure the gitlab-shell API callback URL. Without this, `git push` will
# fail. This can be your 'front door' GitLab URL or an internal load
# balancer.
# Don't forget to copy `/etc/gitlab/gitlab-secrets.json` from web server to Gitaly server.
gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
# Make Gitaly accept connections on all network interfaces. You must use
@ -1425,9 +1453,8 @@ On each node:
})
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and
then replace the file of the same name on this server. If that file isn't on
this server, add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
@ -1536,29 +1563,19 @@ To configure the Sidekiq nodes, one each one:
1. Open `/etc/gitlab/gitlab.rb` with your editor:
```ruby
########################################
##### Services Disabled ###
########################################
nginx['enable'] = false
grafana['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
# Avoid running unnecessary services on the Sidekiq server
gitaly['enable'] = false
gitlab_workhorse['enable'] = false
nginx['enable'] = false
puma['enable'] = false
postgres_exporter['enable'] = false
postgresql['enable'] = false
redis['enable'] = false
redis_exporter['enable'] = false
puma['enable'] = false
gitlab_workhorse['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
grafana['enable'] = false
gitlab_exporter['enable'] = false
nginx['enable'] = false
########################################
#### Redis ###
########################################
## Must be the same in every sentinel node
# Redis
redis['master_name'] = 'gitlab-redis'
## The same password for Redis authentication you set up for the master node.
@ -1571,13 +1588,10 @@ To configure the Sidekiq nodes, one each one:
{'host' => '10.6.0.13', 'port' => 26379},
]
#######################################
### Gitaly ###
#######################################
# git_data_dirs get configured for the Praefect virtual storage
# Address is Internal Load Balancer for Praefect
# Token is praefect_external_token
# Gitaly Cluster
## git_data_dirs get configured for the Praefect virtual storage
## Address is Internal Load Balancer for Praefect
## Token is praefect_external_token
git_data_dirs({
"default" => {
"gitaly_address" => "tcp://10.6.0.40:2305", # internal load balancer IP
@ -1585,31 +1599,26 @@ To configure the Sidekiq nodes, one each one:
}
})
#######################################
### Postgres ###
#######################################
# PostgreSQL
gitlab_rails['db_host'] = '10.6.0.40' # internal load balancer IP
gitlab_rails['db_port'] = 6432
gitlab_rails['db_password'] = '<postgresql_user_password>'
gitlab_rails['db_adapter'] = 'postgresql'
gitlab_rails['db_encoding'] = 'unicode'
# Prevent database migrations from running on upgrade automatically
## Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false
#######################################
### Sidekiq configuration ###
#######################################
# Sidekiq
sidekiq['enable'] = true
sidekiq['listen_address'] = "0.0.0.0"
# Set number of Sidekiq queue processes to the same number as available CPUs
## Set number of Sidekiq queue processes to the same number as available CPUs
sidekiq['queue_groups'] = ['*'] * 2
# Set number of Sidekiq threads per queue process to the recommend number of 10
## Set number of Sidekiq threads per queue process to the recommend number of 10
sidekiq['max_concurrency'] = 10
#######################################
### Monitoring configuration ###
#######################################
# Monitoring
consul['enable'] = true
consul['monitoring_service_discovery'] = true
@ -1617,19 +1626,16 @@ To configure the Sidekiq nodes, one each one:
retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}
# Set the network addresses that the exporters will listen on
## Set the network addresses that the exporters will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'
# Rails Status for prometheus
## Add the monitoring node's IP address to the monitoring whitelist
gitlab_rails['monitoring_whitelist'] = ['10.6.0.81/32', '127.0.0.0/8']
gitlab_rails['prometheus_address'] = '10.6.0.81:9090'
#############################
### Object storage ###
#############################
# This is an example for configuring Object Storage on GCP
# Replace this config with your chosen Object Storage provider as desired
# Object Storage
## This is an example for configuring Object Storage on GCP
## Replace this config with your chosen Object Storage provider as desired
gitlab_rails['object_store']['connection'] = {
'provider' => 'Google',
'google_project' => '<gcp-project-name>',
@ -1643,9 +1649,28 @@ To configure the Sidekiq nodes, one each one:
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
gitlab_rails['backup_upload_connection'] = {
'provider' => 'Google',
'google_project' => '<gcp-project-name>',
'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
```shell
sudo touch /etc/gitlab/skip-auto-reconfigure
```
Only a single designated node should handle migrations as detailed in the
[GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. Verify the GitLab services are running:
```shell
@ -1792,10 +1817,7 @@ On each node perform the following:
#registry['uid'] = 9002
#registry['gid'] = 9002
#############################
### Object storage ###
#############################
# Object storage
# This is an example for configuring Object Storage on GCP
# Replace this config with your chosen Object Storage provider as desired
gitlab_rails['object_store']['connection'] = {
@ -1810,6 +1832,13 @@ On each node perform the following:
gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
gitlab_rails['backup_upload_connection'] = {
'provider' => 'Google',
'google_project' => '<gcp-project-name>',
'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
```
1. If you're using [Gitaly with TLS support](#gitaly-cluster-tls-support), make sure the
@ -1830,7 +1859,20 @@ On each node perform the following:
sudo cp cert.pem /etc/gitlab/trusted-certs/
```
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
```shell
sudo touch /etc/gitlab/skip-auto-reconfigure
```
Only a single designated node should handle migrations as detailed in the
[GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Run `sudo gitlab-rake gitlab:gitaly:check` to confirm the node can connect to Gitaly.
1. Tail the logs to see the requests:
@ -1838,11 +1880,6 @@ On each node perform the following:
sudo gitlab-ctl tail gitaly
```
1. Save the `/etc/gitlab/gitlab-secrets.json` file from one of the two
application nodes and install it on the other application node, the
[Gitaly node](#configure-gitaly) and the [Sidekiq node](#configure-sidekiq) and
[reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. Verify the GitLab services are running:
```shell
@ -1903,19 +1940,14 @@ running [Prometheus](../monitoring/prometheus/index.md) and
```ruby
external_url 'http://gitlab.example.com'
# Disable all other services
alertmanager['enable'] = false
# Avoid running unnecessary services on the Prometheus server
gitaly['enable'] = false
gitlab_exporter['enable'] = false
gitlab_workhorse['enable'] = false
nginx['enable'] = true
postgres_exporter['enable'] = false
postgresql['enable'] = false
redis['enable'] = false
redis_exporter['enable'] = false
sidekiq['enable'] = false
puma['enable'] = false
node_exporter['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
alertmanager['enable'] = false
gitlab_exporter['enable'] = false
# Enable Prometheus

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

@ -420,11 +420,6 @@ The following IPs will be used as an example:
- `10.6.0.12`: Consul 2
- `10.6.0.13`: Consul 3
NOTE:
The configuration processes for the other servers in your reference architecture will
use the `/etc/gitlab/gitlab-secrets.json` file from your Consul server to connect
with the other servers.
To configure Consul:
1. SSH in to the server that will host Consul.
@ -455,7 +450,11 @@ To configure Consul:
gitlab_rails['auto_migrate'] = false
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Go through the steps again for all the other Consul nodes, and
make sure you set up the correct IPs.
@ -612,9 +611,8 @@ PostgreSQL, with Patroni managing its failover, will default to use `pg_rewind`
Like most failover handling methods, this has a small chance of leading to data loss.
Learn more about the various [Patroni replication methods](../postgresql/replication_and_failover.md#selecting-the-appropriate-patroni-replication-method).
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
@ -714,9 +712,8 @@ The following IPs will be used as an example:
node_exporter['listen_address'] = '0.0.0.0:9100'
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
@ -875,9 +872,8 @@ a node and change its status from primary to replica (and vice versa).
gitlab_rails['auto_migrate'] = false
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
@ -942,11 +938,11 @@ You can specify multiple roles, like sentinel and Redis, as:
gitlab_rails['auto_migrate'] = false
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Go through the steps again for all the other replica nodes, and
make sure to set up the IPs correctly.
@ -1074,11 +1070,11 @@ To configure the Sentinel Cache server:
gitlab_rails['auto_migrate'] = false
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Go through the steps again for all the other Consul/Sentinel nodes, and
make sure you set up the correct IPs.
@ -1140,9 +1136,8 @@ a node and change its status from primary to replica (and vice versa).
gitlab_rails['auto_migrate'] = false
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
@ -1201,11 +1196,11 @@ You can specify multiple roles, like sentinel and Redis, as:
gitlab_rails['auto_migrate'] = false
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Go through the steps again for all the other replica nodes, and
make sure to set up the IPs correctly.
@ -1333,7 +1328,7 @@ To configure the Sentinel Queues server:
gitlab_rails['auto_migrate'] = false
```
1. To prevent database migrations from running on upgrade, run:
1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
```shell
sudo touch /etc/gitlab/skip-auto-reconfigure
@ -1341,11 +1336,11 @@ To configure the Sentinel Queues server:
Only the primary GitLab application server should handle migrations.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Go through the steps again for all the other Sentinel nodes, and
make sure you set up the correct IPs.
@ -1444,7 +1439,11 @@ in the second step, do not supply the `EXTERNAL_URL` value.
# END user configuration
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Follow the [post configuration](#praefect-postgresql-post-configuration).
<div align="right">
@ -1542,18 +1541,18 @@ To configure the Praefect nodes, on each one:
1. Edit the `/etc/gitlab/gitlab.rb` file to configure Praefect:
```ruby
# Avoid running unnecessary services on the Gitaly server
# Avoid running unnecessary services on the Praefect server
gitaly['enable'] = false
postgresql['enable'] = false
redis['enable'] = false
nginx['enable'] = false
puma['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
grafana['enable'] = false
# If you run a separate monitoring node you can disable these services
alertmanager['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
grafana['enable'] = false
gitlab_exporter['enable'] = false
nginx['enable'] = false
# Praefect Configuration
praefect['enable'] = true
@ -1621,11 +1620,25 @@ To configure the Praefect nodes, on each one:
# END user configuration
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and
then replace the file of the same name on this server. If that file isn't on
this server, add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. Praefect requires to run some database migrations, much like the main GitLab application. For this
you should select **one Praefect node only to run the migrations**, AKA the _Deploy Node_. This node
must be configured first before the others as follows:
1. In the `/etc/gitlab/gitlab.rb` file, change the `praefect['auto_migrate']` setting value from `false` to `true`
1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
```shell
sudo touch /etc/gitlab/skip-auto-reconfigure
```
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect and
to run the Praefect database migrations.
1. On all other Praefect nodes, [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
### Configure Gitaly
@ -1669,20 +1682,17 @@ On each node:
storage paths, enable the network listener, and to configure the token:
```ruby
# /etc/gitlab/gitlab.rb
# Avoid running unnecessary services on the Gitaly server
postgresql['enable'] = false
redis['enable'] = false
nginx['enable'] = false
puma['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
grafana['enable'] = false
# If you run a separate monitoring node you can disable these services
alertmanager['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
grafana['enable'] = false
gitlab_exporter['enable'] = false
nginx['enable'] = false
# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false
@ -1690,9 +1700,11 @@ On each node:
# Configure the gitlab-shell API callback URL. Without this, `git push` will
# fail. This can be your 'front door' GitLab URL or an internal load
# balancer.
# Don't forget to copy `/etc/gitlab/gitlab-secrets.json` from web server to Gitaly server.
gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
# Gitaly
gitaly['enable'] = true
# Make Gitaly accept connections on all network interfaces. You must use
# firewalls to restrict access to this address/port.
# Comment out following line if you only want to support TLS connections
@ -1734,9 +1746,8 @@ On each node:
})
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and
then replace the file of the same name on this server. If that file isn't on
this server, add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
@ -1843,28 +1854,19 @@ To configure the Sidekiq nodes, on each one:
1. Open `/etc/gitlab/gitlab.rb` with your editor:
```ruby
########################################
##### Services Disabled ###
########################################
nginx['enable'] = false
grafana['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
# Avoid running unnecessary services on the Sidekiq server
gitaly['enable'] = false
gitlab_workhorse['enable'] = false
nginx['enable'] = false
puma['enable'] = false
postgres_exporter['enable'] = false
postgresql['enable'] = false
redis['enable'] = false
redis_exporter['enable'] = false
puma['enable'] = false
gitlab_workhorse['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
grafana['enable'] = false
gitlab_exporter['enable'] = false
nginx['enable'] = false
########################################
#### Redis ###
########################################
# Redis
## Redis connection details
## First cluster that will host the cache
gitlab_rails['redis_cache_instance'] = 'redis://:<REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER>@gitlab-redis-cache'
@ -1896,10 +1898,7 @@ To configure the Sidekiq nodes, on each one:
{host: '10.6.0.83', port: 26379},
]
#######################################
### Gitaly ###
#######################################
# Gitaly
# git_data_dirs get configured for the Praefect virtual storage
# Address is Internal Load Balancer for Praefect
# Token is praefect_external_token
@ -1910,31 +1909,26 @@ To configure the Sidekiq nodes, on each one:
}
})
#######################################
### Postgres ###
#######################################
# PostgreSQL
gitlab_rails['db_host'] = '10.6.0.20' # internal load balancer IP
gitlab_rails['db_port'] = 6432
gitlab_rails['db_password'] = '<postgresql_user_password>'
gitlab_rails['db_adapter'] = 'postgresql'
gitlab_rails['db_encoding'] = 'unicode'
# Prevent database migrations from running on upgrade automatically
## Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false
#######################################
### Sidekiq configuration ###
#######################################
# Sidekiq
sidekiq['enable'] = true
sidekiq['listen_address'] = "0.0.0.0"
# Set number of Sidekiq queue processes to the same number as available CPUs
## Set number of Sidekiq queue processes to the same number as available CPUs
sidekiq['queue_groups'] = ['*'] * 4
# Set number of Sidekiq threads per queue process to the recommend number of 10
## Set number of Sidekiq threads per queue process to the recommend number of 10
sidekiq['max_concurrency'] = 10
#######################################
### Monitoring configuration ###
#######################################
# Monitoring
consul['enable'] = true
consul['monitoring_service_discovery'] = true
@ -1945,15 +1939,12 @@ To configure the Sidekiq nodes, on each one:
# Set the network addresses that the exporters will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'
# Rails Status for prometheus
## Add the monitoring node's IP address to the monitoring whitelist
gitlab_rails['monitoring_whitelist'] = ['10.6.0.151/32', '127.0.0.0/8']
#############################
### Object storage ###
#############################
# This is an example for configuring Object Storage on GCP
# Replace this config with your chosen Object Storage provider as desired
# Object storage
## This is an example for configuring Object Storage on GCP
## Replace this config with your chosen Object Storage provider as desired
gitlab_rails['object_store']['connection'] = {
'provider' => 'Google',
'google_project' => '<gcp-project-name>',
@ -1966,11 +1957,26 @@ To configure the Sidekiq nodes, on each one:
gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
gitlab_rails['backup_upload_connection'] = {
'provider' => 'Google',
'google_project' => '<gcp-project-name>',
'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
```shell
sudo touch /etc/gitlab/skip-auto-reconfigure
```
Only a single designated node should handle migrations as detailed in the
[GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
@ -2010,9 +2016,6 @@ On each node perform the following:
1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
package of your choice. Be sure to follow _only_ installation steps 1 and 2
on the page.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Edit `/etc/gitlab/gitlab.rb` and use the following configuration.
To maintain uniformity of links across nodes, the `external_url`
@ -2107,9 +2110,15 @@ On each node perform the following:
gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
gitlab_rails['backup_upload_connection'] = {
'provider' => 'Google',
'google_project' => '<gcp-project-name>',
'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
```
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. If you're using [Gitaly with TLS support](#gitaly-cluster-tls-support), make sure the
`git_data_dirs` entry is configured with `tls` instead of `tcp`:
@ -2128,6 +2137,20 @@ On each node perform the following:
sudo cp cert.pem /etc/gitlab/trusted-certs/
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
```shell
sudo touch /etc/gitlab/skip-auto-reconfigure
```
Only a single designated node should handle migrations as detailed in the
[GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. If you're [using NFS](#configure-nfs-optional):
1. If necessary, install the NFS client utility packages using the following
commands:
@ -2167,7 +2190,7 @@ On each node perform the following:
registry['gid'] = 9002
```
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. Confirm the node can connect to Gitaly:
```shell
@ -2231,28 +2254,20 @@ To configure the Monitoring node:
1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
package of your choice. Be sure to follow _only_ installation steps 1 and 2
on the page.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
```ruby
external_url 'http://gitlab.example.com'
# Disable all other services
alertmanager['enable'] = false
# Avoid running unnecessary services on the Prometheus server
gitaly['enable'] = false
gitlab_exporter['enable'] = false
gitlab_workhorse['enable'] = false
nginx['enable'] = true
postgres_exporter['enable'] = false
postgresql['enable'] = false
redis['enable'] = false
redis_exporter['enable'] = false
sidekiq['enable'] = false
puma['enable'] = false
node_exporter['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
alertmanager['enable'] = false
gitlab_exporter['enable'] = false
# Enable Prometheus

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

@ -500,6 +500,9 @@ a node and change its status from primary to replica (and vice versa).
gitlab_rails['auto_migrate'] = false
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
You can specify multiple roles, like sentinel and Redis, as:
@ -583,6 +586,9 @@ run: redis-exporter: (pid 30075) 76861s; run: log: (pid 29674) 76896s
gitlab_rails['auto_migrate'] = false
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Go through the steps again for all the other replica nodes, and
make sure to set up the IPs correctly.
@ -712,6 +718,9 @@ To configure the Sentinel:
gitlab_rails['auto_migrate'] = false
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Go through the steps again for all the other Consul/Sentinel nodes, and
make sure you set up the correct IPs.
@ -870,9 +879,8 @@ PostgreSQL, with Patroni managing its failover, will default to use `pg_rewind`
Like most failover handling methods, this has a small chance of leading to data loss.
Learn more about the various [Patroni replication methods](../postgresql/replication_and_failover.md#selecting-the-appropriate-patroni-replication-method).
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
the file of the same name on this server. If that file is not on this server,
add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
@ -973,6 +981,9 @@ The following IPs will be used as an example:
pgbouncer_exporter['listen_address'] = '0.0.0.0:9188'
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Create a `.pgpass` file so Consul is able to
@ -1126,7 +1137,11 @@ in the second step, do not supply the `EXTERNAL_URL` value.
# END user configuration
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Follow the [post configuration](#praefect-postgresql-post-configuration).
<div align="right">
@ -1224,18 +1239,18 @@ To configure the Praefect nodes, on each one:
1. Edit the `/etc/gitlab/gitlab.rb` file to configure Praefect:
```ruby
# Avoid running unnecessary services on the Gitaly server
# Avoid running unnecessary services on the Praefect server
gitaly['enable'] = false
postgresql['enable'] = false
redis['enable'] = false
nginx['enable'] = false
puma['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
grafana['enable'] = false
# If you run a separate monitoring node you can disable these services
alertmanager['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
grafana['enable'] = false
gitlab_exporter['enable'] = false
nginx['enable'] = false
# Praefect Configuration
praefect['enable'] = true
@ -1303,11 +1318,25 @@ To configure the Praefect nodes, on each one:
# END user configuration
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and
then replace the file of the same name on this server. If that file isn't on
this server, add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. Praefect requires to run some database migrations, much like the main GitLab application. For this
you should select **one Praefect node only to run the migrations**, AKA the _Deploy Node_. This node
must be configured first before the others as follows:
1. In the `/etc/gitlab/gitlab.rb` file, change the `praefect['auto_migrate']` setting value from `false` to `true`
1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
```shell
sudo touch /etc/gitlab/skip-auto-reconfigure
```
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect and
to run the Praefect database migrations.
1. On all other Praefect nodes, [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
### Configure Gitaly
@ -1351,20 +1380,17 @@ On each node:
storage paths, enable the network listener, and to configure the token:
```ruby
# /etc/gitlab/gitlab.rb
# Avoid running unnecessary services on the Gitaly server
postgresql['enable'] = false
redis['enable'] = false
nginx['enable'] = false
puma['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
grafana['enable'] = false
# If you run a separate monitoring node you can disable these services
alertmanager['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
grafana['enable'] = false
gitlab_exporter['enable'] = false
nginx['enable'] = false
# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false
@ -1372,9 +1398,11 @@ On each node:
# Configure the gitlab-shell API callback URL. Without this, `git push` will
# fail. This can be your 'front door' GitLab URL or an internal load
# balancer.
# Don't forget to copy `/etc/gitlab/gitlab-secrets.json` from web server to Gitaly server.
gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
# Gitaly
gitaly['enable'] = true
# Make Gitaly accept connections on all network interfaces. You must use
# firewalls to restrict access to this address/port.
# Comment out following line if you only want to support TLS connections
@ -1416,9 +1444,8 @@ On each node:
})
```
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and
then replace the file of the same name on this server. If that file isn't on
this server, add the file from your Consul server to this server.
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
@ -1525,28 +1552,19 @@ To configure the Sidekiq nodes, one each one:
1. Open `/etc/gitlab/gitlab.rb` with your editor:
```ruby
########################################
##### Services Disabled ###
########################################
nginx['enable'] = false
grafana['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
# Avoid running unnecessary services on the Sidekiq server
gitaly['enable'] = false
gitlab_workhorse['enable'] = false
nginx['enable'] = false
puma['enable'] = false
postgres_exporter['enable'] = false
postgresql['enable'] = false
redis['enable'] = false
redis_exporter['enable'] = false
puma['enable'] = false
gitlab_workhorse['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
grafana['enable'] = false
gitlab_exporter['enable'] = false
nginx['enable'] = false
########################################
#### Redis ###
########################################
# Redis
## Must be the same in every sentinel node
redis['master_name'] = 'gitlab-redis'
@ -1560,13 +1578,10 @@ To configure the Sidekiq nodes, one each one:
{'host' => '10.6.0.13', 'port' => 26379},
]
#######################################
### Gitaly ###
#######################################
# git_data_dirs get configured for the Praefect virtual storage
# Address is Internal Load Balancer for Praefect
# Token is praefect_external_token
# Gitaly Cluster
## git_data_dirs get configured for the Praefect virtual storage
## Address is Internal Load Balancer for Praefect
## Token is praefect_external_token
git_data_dirs({
"default" => {
"gitaly_address" => "tcp://10.6.0.40:2305", # internal load balancer IP
@ -1574,31 +1589,26 @@ To configure the Sidekiq nodes, one each one:
}
})
#######################################
### Postgres ###
#######################################
# PostgreSQL
gitlab_rails['db_host'] = '10.6.0.40' # internal load balancer IP
gitlab_rails['db_port'] = 6432
gitlab_rails['db_password'] = '<postgresql_user_password>'
gitlab_rails['db_adapter'] = 'postgresql'
gitlab_rails['db_encoding'] = 'unicode'
# Prevent database migrations from running on upgrade automatically
## Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false
#######################################
### Sidekiq configuration ###
#######################################
# Sidekiq
sidekiq['enable'] = true
sidekiq['listen_address'] = "0.0.0.0"
# Set number of Sidekiq queue processes to the same number as available CPUs
## Set number of Sidekiq queue processes to the same number as available CPUs
sidekiq['queue_groups'] = ['*'] * 4
# Set number of Sidekiq threads per queue process to the recommend number of 10
## Set number of Sidekiq threads per queue process to the recommend number of 10
sidekiq['max_concurrency'] = 10
#######################################
### Monitoring configuration ###
#######################################
# Monitoring
consul['enable'] = true
consul['monitoring_service_discovery'] = true
@ -1606,19 +1616,16 @@ To configure the Sidekiq nodes, one each one:
retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}
# Set the network addresses that the exporters will listen on
## Set the network addresses that the exporters will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'
# Rails Status for prometheus
## Add the monitoring node's IP address to the monitoring whitelist
gitlab_rails['monitoring_whitelist'] = ['10.6.0.81/32', '127.0.0.0/8']
gitlab_rails['prometheus_address'] = '10.6.0.81:9090'
#############################
### Object storage ###
#############################
# This is an example for configuring Object Storage on GCP
# Replace this config with your chosen Object Storage provider as desired
# Object Storage
## This is an example for configuring Object Storage on GCP
## Replace this config with your chosen Object Storage provider as desired
gitlab_rails['object_store']['connection'] = {
'provider' => 'Google',
'google_project' => '<gcp-project-name>',
@ -1631,9 +1638,29 @@ To configure the Sidekiq nodes, one each one:
gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
gitlab_rails['backup_upload_connection'] = {
'provider' => 'Google',
'google_project' => '<gcp-project-name>',
'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
```
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
```shell
sudo touch /etc/gitlab/skip-auto-reconfigure
```
Only a single designated node should handle migrations as detailed in the
[GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Verify the GitLab services are running:
```shell
@ -1784,6 +1811,13 @@ On each node perform the following:
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
gitlab_rails['backup_upload_connection'] = {
'provider' => 'Google',
'google_project' => '<gcp-project-name>',
'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
## Uncomment and edit the following options if you have set up NFS
##
## Prevent GitLab from starting if NFS data mounts are not available
@ -1818,7 +1852,20 @@ On each node perform the following:
sudo cp cert.pem /etc/gitlab/trusted-certs/
```
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
```shell
sudo touch /etc/gitlab/skip-auto-reconfigure
```
Only a single designated node should handle migrations as detailed in the
[GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Run `sudo gitlab-rake gitlab:gitaly:check` to confirm the node can connect to Gitaly.
1. Tail the logs to see the requests:
@ -1826,11 +1873,6 @@ On each node perform the following:
sudo gitlab-ctl tail gitaly
```
1. Save the `/etc/gitlab/gitlab-secrets.json` file from one of the two
application nodes and install it on the other application node, the
[Gitaly node](#configure-gitaly) and the [Sidekiq node](#configure-sidekiq) and
[reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. Verify the GitLab services are running:
```shell
@ -1891,7 +1933,7 @@ running [Prometheus](../monitoring/prometheus/index.md) and
```ruby
external_url 'http://gitlab.example.com'
# Disable all other services
# Avoid running unnecessary services on the Prometheus server
alertmanager['enable'] = false
gitaly['enable'] = false
gitlab_exporter['enable'] = false

280
doc/api/graphql/reference/index.md
View File

@ -87,7 +87,7 @@ Returns [`DesignManagement!`](#designmanagement).
Get configured DevOps adoption namespaces. **BETA** This endpoint is subject to change without notice.
Returns [`DevopsAdoptionSegmentConnection`](#devopsadoptionsegmentconnection).
Returns [`DevopsAdoptionEnabledNamespaceConnection`](#devopsadoptionenablednamespaceconnection).
This field returns a [connection](#connections). It accepts the
four standard [pagination arguments](#connection-pagination-arguments):
@ -455,30 +455,6 @@ four standard [pagination arguments](#connection-pagination-arguments):
| <a id="queryvulnerabilitiescountbydayenddate"></a>`endDate` | [`ISO8601Date!`](#iso8601date) | Last day for which to fetch vulnerability history. |
| <a id="queryvulnerabilitiescountbydaystartdate"></a>`startDate` | [`ISO8601Date!`](#iso8601date) | First day for which to fetch vulnerability history. |
### `Query.vulnerabilitiesCountByDayAndSeverity`
Number of vulnerabilities per severity level, per day, for the projects on the
current user's instance security dashboard.
.
WARNING:
**Deprecated** in 13.3.
Use of this is not recommended.
Use: [`Query.vulnerabilitiesCountByDay`](#queryvulnerabilitiescountbyday).
Returns [`VulnerabilitiesCountByDayAndSeverityConnection`](#vulnerabilitiescountbydayandseverityconnection).
This field returns a [connection](#connections). It accepts the
four standard [pagination arguments](#connection-pagination-arguments):
`before: String`, `after: String`, `first: Int`, `last: Int`.
#### Arguments
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="queryvulnerabilitiescountbydayandseverityenddate"></a>`endDate` | [`ISO8601Date!`](#iso8601date) | Last day for which to fetch vulnerability history. |
| <a id="queryvulnerabilitiescountbydayandseveritystartdate"></a>`startDate` | [`ISO8601Date!`](#iso8601date) | First day for which to fetch vulnerability history. |
### `Query.vulnerability`
Find a vulnerability.
@ -510,30 +486,6 @@ mutation($id: NoteableID!, $body: String!) {
}
```
### `Mutation.addAwardEmoji`
WARNING:
**Deprecated** in 13.2.
Use awardEmojiAdd.
Input type: `AddAwardEmojiInput`
#### Arguments
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="mutationaddawardemojiawardableid"></a>`awardableId` | [`AwardableID!`](#awardableid) | The global ID of the awardable resource. |
| <a id="mutationaddawardemojiclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
| <a id="mutationaddawardemojiname"></a>`name` | [`String!`](#string) | The emoji name. |
#### Fields
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="mutationaddawardemojiawardemoji"></a>`awardEmoji` | [`AwardEmoji`](#awardemoji) | The award emoji after mutation. |
| <a id="mutationaddawardemojiclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
| <a id="mutationaddawardemojierrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
### `Mutation.addProjectToSecurityDashboard`
Input type: `AddProjectToSecurityDashboardInput`
@ -801,7 +753,7 @@ Input type: `BulkEnableDevopsAdoptionNamespacesInput`
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="mutationbulkenabledevopsadoptionnamespacesclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
| <a id="mutationbulkenabledevopsadoptionnamespacesenablednamespaces"></a>`enabledNamespaces` | [`[DevopsAdoptionSegment!]`](#devopsadoptionsegment) | Enabled namespaces after mutation. |
| <a id="mutationbulkenabledevopsadoptionnamespacesenablednamespaces"></a>`enabledNamespaces` | [`[DevopsAdoptionEnabledNamespace!]`](#devopsadoptionenablednamespace) | Enabled namespaces after mutation. |
| <a id="mutationbulkenabledevopsadoptionnamespaceserrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
### `Mutation.ciCdSettingsUpdate`
@ -1485,7 +1437,6 @@ Input type: `DastScannerProfileCreateInput`
| ---- | ---- | ----------- |
| <a id="mutationdastscannerprofilecreateclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
| <a id="mutationdastscannerprofilecreateerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
| <a id="mutationdastscannerprofilecreateglobalid"></a>`globalId` **{warning-solid}** | [`DastScannerProfileID`](#dastscannerprofileid) | **Deprecated:** Use `id`. Deprecated in 13.6. |
| <a id="mutationdastscannerprofilecreateid"></a>`id` | [`DastScannerProfileID`](#dastscannerprofileid) | ID of the scanner profile. |
### `Mutation.dastScannerProfileDelete`
@ -1943,31 +1894,6 @@ Input type: `DiscussionToggleResolveInput`
| <a id="mutationdiscussiontoggleresolvediscussion"></a>`discussion` | [`Discussion`](#discussion) | The discussion after mutation. |
| <a id="mutationdiscussiontoggleresolveerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
### `Mutation.dismissVulnerability`
WARNING:
**Deprecated** in 13.5.
Use vulnerabilityDismiss.
Input type: `DismissVulnerabilityInput`
#### Arguments
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="mutationdismissvulnerabilityclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
| <a id="mutationdismissvulnerabilitycomment"></a>`comment` | [`String`](#string) | Comment why vulnerability should be dismissed. |
| <a id="mutationdismissvulnerabilitydismissalreason"></a>`dismissalReason` | [`VulnerabilityDismissalReason`](#vulnerabilitydismissalreason) | Reason why vulnerability should be dismissed. |
| <a id="mutationdismissvulnerabilityid"></a>`id` | [`VulnerabilityID!`](#vulnerabilityid) | ID of the vulnerability to be dismissed. |
#### Fields
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="mutationdismissvulnerabilityclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
| <a id="mutationdismissvulnerabilityerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
| <a id="mutationdismissvulnerabilityvulnerability"></a>`vulnerability` | [`Vulnerability`](#vulnerability) | The vulnerability after dismissal. |
### `Mutation.enableDevopsAdoptionNamespace`
**BETA** This endpoint is subject to change without notice.
@ -1987,7 +1913,7 @@ Input type: `EnableDevopsAdoptionNamespaceInput`
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="mutationenabledevopsadoptionnamespaceclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
| <a id="mutationenabledevopsadoptionnamespaceenablednamespace"></a>`enabledNamespace` | [`DevopsAdoptionSegment`](#devopsadoptionsegment) | Enabled namespace after mutation. |
| <a id="mutationenabledevopsadoptionnamespaceenablednamespace"></a>`enabledNamespace` | [`DevopsAdoptionEnabledNamespace`](#devopsadoptionenablednamespace) | Enabled namespace after mutation. |
| <a id="mutationenabledevopsadoptionnamespaceerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
### `Mutation.environmentsCanaryIngressUpdate`
@ -3513,30 +3439,6 @@ Input type: `ReleaseUpdateInput`
| <a id="mutationreleaseupdateerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
| <a id="mutationreleaseupdaterelease"></a>`release` | [`Release`](#release) | The release after mutation. |
### `Mutation.removeAwardEmoji`
WARNING:
**Deprecated** in 13.2.
Use awardEmojiRemove.
Input type: `RemoveAwardEmojiInput`
#### Arguments
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="mutationremoveawardemojiawardableid"></a>`awardableId` | [`AwardableID!`](#awardableid) | The global ID of the awardable resource. |
| <a id="mutationremoveawardemojiclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
| <a id="mutationremoveawardemojiname"></a>`name` | [`String!`](#string) | The emoji name. |
#### Fields
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="mutationremoveawardemojiawardemoji"></a>`awardEmoji` | [`AwardEmoji`](#awardemoji) | The award emoji after mutation. |
| <a id="mutationremoveawardemojiclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
| <a id="mutationremoveawardemojierrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
### `Mutation.removeProjectFromSecurityDashboard`
Input type: `RemoveProjectFromSecurityDashboardInput`
@ -3577,55 +3479,6 @@ Input type: `RepositionImageDiffNoteInput`
| <a id="mutationrepositionimagediffnoteerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
| <a id="mutationrepositionimagediffnotenote"></a>`note` | [`Note`](#note) | The note after mutation. |
### `Mutation.revertVulnerabilityToDetected`
WARNING:
**Deprecated** in 13.5.
Use vulnerabilityRevertToDetected.
Input type: `RevertVulnerabilityToDetectedInput`
#### Arguments
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="mutationrevertvulnerabilitytodetectedclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
| <a id="mutationrevertvulnerabilitytodetectedid"></a>`id` | [`VulnerabilityID!`](#vulnerabilityid) | ID of the vulnerability to be reverted. |
#### Fields
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="mutationrevertvulnerabilitytodetectedclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
| <a id="mutationrevertvulnerabilitytodetectederrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
| <a id="mutationrevertvulnerabilitytodetectedvulnerability"></a>`vulnerability` | [`Vulnerability`](#vulnerability) | The vulnerability after revert. |
### `Mutation.runDastScan`
WARNING:
**Deprecated** in 13.4.
Use DastOnDemandScanCreate.
Input type: `RunDASTScanInput`
#### Arguments
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="mutationrundastscanbranch"></a>`branch` | [`String!`](#string) | The branch to be associated with the scan. |
| <a id="mutationrundastscanclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
| <a id="mutationrundastscanprojectpath"></a>`projectPath` | [`ID!`](#id) | The project the DAST scan belongs to. |
| <a id="mutationrundastscanscantype"></a>`scanType` | [`DastScanTypeEnum!`](#dastscantypeenum) | The type of scan to be run. |
| <a id="mutationrundastscantargeturl"></a>`targetUrl` | [`String!`](#string) | The URL of the target to be scanned. |
#### Fields
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="mutationrundastscanclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
| <a id="mutationrundastscanerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
| <a id="mutationrundastscanpipelineurl"></a>`pipelineUrl` | [`String`](#string) | URL of the pipeline that was created. |
### `Mutation.runnerDelete`
Available only when feature flag `runner_graphql_query` is enabled.
@ -3803,7 +3656,6 @@ Input type: `TodoRestoreManyInput`
| <a id="mutationtodorestoremanyclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
| <a id="mutationtodorestoremanyerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
| <a id="mutationtodorestoremanytodos"></a>`todos` | [`[Todo!]!`](#todo) | Updated to-do items. |
| <a id="mutationtodorestoremanyupdatedids"></a>`updatedIds` **{warning-solid}** | [`[TodoID!]!`](#todoid) | **Deprecated:** Use to-do items. Deprecated in 13.2. |
### `Mutation.todosMarkAllDone`
@ -3822,32 +3674,6 @@ Input type: `TodosMarkAllDoneInput`
| <a id="mutationtodosmarkalldoneclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
| <a id="mutationtodosmarkalldoneerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
| <a id="mutationtodosmarkalldonetodos"></a>`todos` | [`[Todo!]!`](#todo) | Updated to-do items. |
| <a id="mutationtodosmarkalldoneupdatedids"></a>`updatedIds` **{warning-solid}** | [`[TodoID!]!`](#todoid) | **Deprecated:** Use to-do items. Deprecated in 13.2. |
### `Mutation.toggleAwardEmoji`
WARNING:
**Deprecated** in 13.2.
Use awardEmojiToggle.
Input type: `ToggleAwardEmojiInput`
#### Arguments
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="mutationtoggleawardemojiawardableid"></a>`awardableId` | [`AwardableID!`](#awardableid) | The global ID of the awardable resource. |
| <a id="mutationtoggleawardemojiclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
| <a id="mutationtoggleawardemojiname"></a>`name` | [`String!`](#string) | The emoji name. |
#### Fields
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="mutationtoggleawardemojiawardemoji"></a>`awardEmoji` | [`AwardEmoji`](#awardemoji) | The award emoji after mutation. |
| <a id="mutationtoggleawardemojiclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
| <a id="mutationtoggleawardemojierrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
| <a id="mutationtoggleawardemojitoggledon"></a>`toggledOn` | [`Boolean!`](#boolean) | Indicates the status of the emoji. True if the toggle awarded the emoji, and false if the toggle removed the emoji. |
### `Mutation.updateAlertStatus`
@ -5184,28 +5010,28 @@ The edge type for [`DesignVersion`](#designversion).
| <a id="designversionedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
| <a id="designversionedgenode"></a>`node` | [`DesignVersion`](#designversion) | The item at the end of the edge. |
#### `DevopsAdoptionSegmentConnection`
#### `DevopsAdoptionEnabledNamespaceConnection`
The connection type for [`DevopsAdoptionSegment`](#devopsadoptionsegment).
The connection type for [`DevopsAdoptionEnabledNamespace`](#devopsadoptionenablednamespace).
##### Fields
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="devopsadoptionsegmentconnectionedges"></a>`edges` | [`[DevopsAdoptionSegmentEdge]`](#devopsadoptionsegmentedge) | A list of edges. |
| <a id="devopsadoptionsegmentconnectionnodes"></a>`nodes` | [`[DevopsAdoptionSegment]`](#devopsadoptionsegment) | A list of nodes. |
| <a id="devopsadoptionsegmentconnectionpageinfo"></a>`pageInfo` | [`PageInfo!`](#pageinfo) | Information to aid in pagination. |
| <a id="devopsadoptionenablednamespaceconnectionedges"></a>`edges` | [`[DevopsAdoptionEnabledNamespaceEdge]`](#devopsadoptionenablednamespaceedge) | A list of edges. |
| <a id="devopsadoptionenablednamespaceconnectionnodes"></a>`nodes` | [`[DevopsAdoptionEnabledNamespace]`](#devopsadoptionenablednamespace) | A list of nodes. |
| <a id="devopsadoptionenablednamespaceconnectionpageinfo"></a>`pageInfo` | [`PageInfo!`](#pageinfo) | Information to aid in pagination. |
#### `DevopsAdoptionSegmentEdge`
#### `DevopsAdoptionEnabledNamespaceEdge`
The edge type for [`DevopsAdoptionSegment`](#devopsadoptionsegment).
The edge type for [`DevopsAdoptionEnabledNamespace`](#devopsadoptionenablednamespace).
##### Fields
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="devopsadoptionsegmentedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
| <a id="devopsadoptionsegmentedgenode"></a>`node` | [`DevopsAdoptionSegment`](#devopsadoptionsegment) | The item at the end of the edge. |
| <a id="devopsadoptionenablednamespaceedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
| <a id="devopsadoptionenablednamespaceedgenode"></a>`node` | [`DevopsAdoptionEnabledNamespace`](#devopsadoptionenablednamespace) | The item at the end of the edge. |
#### `DiscussionConnection`
@ -6875,29 +6701,6 @@ The edge type for [`UserCore`](#usercore).
| <a id="usercoreedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
| <a id="usercoreedgenode"></a>`node` | [`UserCore`](#usercore) | The item at the end of the edge. |
#### `VulnerabilitiesCountByDayAndSeverityConnection`
The connection type for [`VulnerabilitiesCountByDayAndSeverity`](#vulnerabilitiescountbydayandseverity).
##### Fields
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="vulnerabilitiescountbydayandseverityconnectionedges"></a>`edges` | [`[VulnerabilitiesCountByDayAndSeverityEdge]`](#vulnerabilitiescountbydayandseverityedge) | A list of edges. |
| <a id="vulnerabilitiescountbydayandseverityconnectionnodes"></a>`nodes` | [`[VulnerabilitiesCountByDayAndSeverity]`](#vulnerabilitiescountbydayandseverity) | A list of nodes. |
| <a id="vulnerabilitiescountbydayandseverityconnectionpageinfo"></a>`pageInfo` | [`PageInfo!`](#pageinfo) | Information to aid in pagination. |
#### `VulnerabilitiesCountByDayAndSeverityEdge`
The edge type for [`VulnerabilitiesCountByDayAndSeverity`](#vulnerabilitiescountbydayandseverity).
##### Fields
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="vulnerabilitiescountbydayandseverityedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
| <a id="vulnerabilitiescountbydayandseverityedgenode"></a>`node` | [`VulnerabilitiesCountByDayAndSeverity`](#vulnerabilitiescountbydayandseverity) | The item at the end of the edge. |
#### `VulnerabilitiesCountByDayConnection`
The connection type for [`VulnerabilitiesCountByDay`](#vulnerabilitiescountbyday).
@ -8043,7 +7846,6 @@ Represents a DAST scanner profile.
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="dastscannerprofileeditpath"></a>`editPath` | [`String`](#string) | Relative web path to the edit page of a scanner profile. |
| <a id="dastscannerprofileglobalid"></a>`globalId` **{warning-solid}** | [`DastScannerProfileID!`](#dastscannerprofileid) | **Deprecated** in 13.6. Use `id`. |
| <a id="dastscannerprofileid"></a>`id` | [`DastScannerProfileID!`](#dastscannerprofileid) | ID of the DAST scanner profile. |
| <a id="dastscannerprofileprofilename"></a>`profileName` | [`String`](#string) | Name of the DAST scanner profile. |
| <a id="dastscannerprofilereferencedinsecuritypolicies"></a>`referencedInSecurityPolicies` | [`[String!]`](#string) | List of security policy names that are referencing given project. |
@ -8378,7 +8180,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
| <a id="detailedstatustext"></a>`text` | [`String`](#string) | Text of the status. |
| <a id="detailedstatustooltip"></a>`tooltip` | [`String`](#string) | Tooltip associated with the status. |
### `DevopsAdoptionSegment`
### `DevopsAdoptionEnabledNamespace`
Enabled namespace for DevopsAdoption.
@ -8386,10 +8188,10 @@ Enabled namespace for DevopsAdoption.
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="devopsadoptionsegmentdisplaynamespace"></a>`displayNamespace` | [`Namespace`](#namespace) | Namespace where data should be displayed. |
| <a id="devopsadoptionsegmentid"></a>`id` | [`ID!`](#id) | ID of the enabled namespace. |
| <a id="devopsadoptionsegmentlatestsnapshot"></a>`latestSnapshot` | [`DevopsAdoptionSnapshot`](#devopsadoptionsnapshot) | The latest adoption metrics for the enabled namespace. |
| <a id="devopsadoptionsegmentnamespace"></a>`namespace` | [`Namespace`](#namespace) | Namespace which should be calculated. |
| <a id="devopsadoptionenablednamespacedisplaynamespace"></a>`displayNamespace` | [`Namespace`](#namespace) | Namespace where data should be displayed. |
| <a id="devopsadoptionenablednamespaceid"></a>`id` | [`ID!`](#id) | ID of the enabled namespace. |
| <a id="devopsadoptionenablednamespacelatestsnapshot"></a>`latestSnapshot` | [`DevopsAdoptionSnapshot`](#devopsadoptionsnapshot) | The latest adoption metrics for the enabled namespace. |
| <a id="devopsadoptionenablednamespacenamespace"></a>`namespace` | [`Namespace`](#namespace) | Namespace which should be calculated. |
### `DevopsAdoptionSnapshot`
@ -9558,27 +9360,6 @@ four standard [pagination arguments](#connection-pagination-arguments):
| <a id="groupvulnerabilitiescountbydayenddate"></a>`endDate` | [`ISO8601Date!`](#iso8601date) | Last day for which to fetch vulnerability history. |
| <a id="groupvulnerabilitiescountbydaystartdate"></a>`startDate` | [`ISO8601Date!`](#iso8601date) | First day for which to fetch vulnerability history. |
##### `Group.vulnerabilitiesCountByDayAndSeverity`
Number of vulnerabilities per severity level, per day, for the projects in the group and its subgroups.
WARNING:
**Deprecated** in 13.3.
Use `vulnerabilitiesCountByDay`.
Returns [`VulnerabilitiesCountByDayAndSeverityConnection`](#vulnerabilitiescountbydayandseverityconnection).
This field returns a [connection](#connections). It accepts the
four standard [pagination arguments](#connection-pagination-arguments):
`before: String`, `after: String`, `first: Int`, `last: Int`.
###### Arguments
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="groupvulnerabilitiescountbydayandseverityenddate"></a>`endDate` | [`ISO8601Date!`](#iso8601date) | Last day for which to fetch vulnerability history. |
| <a id="groupvulnerabilitiescountbydayandseveritystartdate"></a>`startDate` | [`ISO8601Date!`](#iso8601date) | First day for which to fetch vulnerability history. |
##### `Group.vulnerabilityGrades`
Represents vulnerable project counts for each grade.
@ -12417,18 +12198,6 @@ Counts of requirements by their state.
| <a id="rootstoragestatisticsuploadssize"></a>`uploadsSize` | [`Float!`](#float) | The uploads size in bytes. |
| <a id="rootstoragestatisticswikisize"></a>`wikiSize` | [`Float!`](#float) | The wiki size in bytes. |
### `RunDASTScanPayload`
Autogenerated return type of RunDASTScan.
#### Fields
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="rundastscanpayloadclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
| <a id="rundastscanpayloaderrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
| <a id="rundastscanpayloadpipelineurl"></a>`pipelineUrl` | [`String`](#string) | URL of the pipeline that was created. |
### `RunnerArchitecture`
#### Fields
@ -12771,7 +12540,6 @@ Represents a snippet entry.
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="snippetauthor"></a>`author` | [`UserCore`](#usercore) | The owner of the snippet. |
| <a id="snippetblob"></a>`blob` **{warning-solid}** | [`SnippetBlob!`](#snippetblob) | **Deprecated** in 13.3. Use `blobs`. |
| <a id="snippetcreatedat"></a>`createdAt` | [`Time!`](#time) | Timestamp this snippet was created. |
| <a id="snippetdescription"></a>`description` | [`String`](#string) | Description of the snippet. |
| <a id="snippetdescriptionhtml"></a>`descriptionHtml` | [`String`](#string) | The GitLab Flavored Markdown rendering of `description`. |
@ -13389,18 +13157,6 @@ Represents the count of vulnerabilities by severity on a particular day. This da
| <a id="vulnerabilitiescountbydaytotal"></a>`total` | [`Int!`](#int) | Total number of vulnerabilities on a particular day. |
| <a id="vulnerabilitiescountbydayunknown"></a>`unknown` | [`Int!`](#int) | Total number of vulnerabilities on a particular day with unknown severity. |
### `VulnerabilitiesCountByDayAndSeverity`
Represents the number of vulnerabilities for a particular severity on a particular day. This data is retained for 365 days.
#### Fields
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="vulnerabilitiescountbydayandseveritycount"></a>`count` | [`Int`](#int) | Number of vulnerabilities. |
| <a id="vulnerabilitiescountbydayandseverityday"></a>`day` | [`ISO8601Date`](#iso8601date) | Date for the count. |
| <a id="vulnerabilitiescountbydayandseverityseverity"></a>`severity` | [`VulnerabilitySeverity`](#vulnerabilityseverity) | Severity of the counted vulnerabilities. |
### `Vulnerability`
Represents a vulnerability.
@ -14662,6 +14418,8 @@ Values for sorting group packages.
| <a id="packagegroupsortcreated_desc"></a>`CREATED_DESC` | Ordered by created_at in descending order. |
| <a id="packagegroupsortname_asc"></a>`NAME_ASC` | Ordered by name in ascending order. |
| <a id="packagegroupsortname_desc"></a>`NAME_DESC` | Ordered by name in descending order. |
| <a id="packagegroupsortproject_path_asc"></a>`PROJECT_PATH_ASC` | Ordered by project path in ascending order. |
| <a id="packagegroupsortproject_path_desc"></a>`PROJECT_PATH_DESC` | Ordered by project path in descending order. |
| <a id="packagegroupsorttype_asc"></a>`TYPE_ASC` | Ordered by type in ascending order. |
| <a id="packagegroupsorttype_desc"></a>`TYPE_DESC` | Ordered by type in descending order. |
| <a id="packagegroupsortversion_asc"></a>`VERSION_ASC` | Ordered by version in ascending order. |

26
doc/api/graphql/removed_items.md
View File

@ -10,6 +10,32 @@ GraphQL is a versionless API, unlike the REST API.
Occasionally, items have to be updated or removed from the GraphQL API.
According to our [process for removing items](index.md#deprecation-and-removal-process), here are the items that have been removed.
## GitLab 14.0
Fields removed in [GitLab 14.0](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/63293):
### GraphQL Mutations
| Argument name | Mutation | Deprecated in | Use instead |
| -------------------- | -------------------- | ------------- | -------------------------- |
| `updated_ids` | `todosMarkAllDone` | 13.2 | `todos` |
| `updated_ids` | `todoRestoreMany` | 13.2 | `todos` |
| `global_id` | `dastScannerProfileCreate`| 13.6 | `todos` |
| - | `addAwardEmoji` | 13.2 | `awardEmojiAdd` |
| - | `removeAwardEmoji` | 13.2 | `awardEmojiRemove` |
| - | `toggleAwardEmoji` | 13.2 | `ToggleAwardEmoji` |
| - | `runDastScan` | 13.5 | `dastOnDemandScanCreate` |
| - | `dismissVulnerability` | 13.5 | `vulnerabilityDismiss` |
| - | `revertVulnerabilityToDetected` | 13.5 | `vulnerabilityRevertToDetected` |
### GraphQL Types
| Field name | GraphQL type | Deprecated in | Use instead |
| -------------------- | -------------------- | ------------- | -------------------------- |
| `blob` | `SnippetType` | 13.3 | `blobs` |
| `global_id` | `DastScannerProfileType` | 13.6 | `blobs` |
| `vulnerabilities_count_by_day_and_severity` | `GroupType`, `QueryType` | 13.3 | None. Plaintext tokens no longer supported for security reasons. |
## GitLab 13.6
Fields removed in [GitLab 13.6](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/44866):

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

@ -43,9 +43,9 @@ can't link to files outside it.
To ensure maximum availability of the cache, when you declare `cache` in your jobs,
use one or more of the following:
- [Tag your runners](../runners/README.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) and use the tag on jobs
- [Tag your runners](../runners/configure_runners.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) and use the tag on jobs
that share their cache.
- [Use runners that are only available to a particular project](../runners/README.md#prevent-a-specific-runner-from-being-enabled-for-other-projects).
- [Use runners that are only available to a particular project](../runners/runners_scope.md#prevent-a-specific-runner-from-being-enabled-for-other-projects).
- [Use a `key`](../yaml/README.md#cachekey) that fits your workflow (for example,
different caches on each branch). For that, you can take advantage of the
[predefined CI/CD variables](../variables/README.md#predefined-cicd-variables).

7
doc/ci/docker/using_docker_build.md
View File

@ -25,9 +25,8 @@ To enable Docker commands for your CI/CD jobs, you can use:
If you don't want to execute a runner in privileged mode,
but want to use `docker build`, you can also [use kaniko](using_kaniko.md).
If you are using shared runners on GitLab.com, see
[GitLab.com shared runners](../../user/gitlab_com/index.md#shared-runners)
to learn more about how these runners are configured.
If you are using shared runners on GitLab.com,
[learn more about how these runners are configured](../runners/README.md).
### Use the shell executor
@ -91,7 +90,7 @@ The Docker image has all of the `docker` tools installed and can run
the job script in context of the image in privileged mode.
We recommend you use [Docker-in-Docker with TLS enabled](#docker-in-docker-with-tls-enabled),
which is supported by [GitLab.com shared runners](../../user/gitlab_com/index.md#shared-runners).
which is supported by [GitLab.com shared runners](../runners/README.md).
You should always specify a specific version of the image, like `docker:19.03.12`.
If you use a tag like `docker:stable`, you have no control over which version is used.

2
doc/ci/docker/using_kaniko.md
View File

@ -133,7 +133,7 @@ The [Least Privilege Container Builds with Kaniko on GitLab](https://www.youtube
video is a walkthrough of the [Kaniko Docker Build](https://gitlab.com/guided-explorations/containers/kaniko-docker-build)
Guided Exploration project pipeline. It was tested on:
- [GitLab.com shared runners](../../user/gitlab_com/index.md#shared-runners)
- [GitLab.com shared runners](../runners/README.md)
- [The Kubernetes runner executor](https://docs.gitlab.com/runner/executors/kubernetes.html)
The example can be copied to your own group or instance for testing. More details

2
doc/ci/environments/deployment_safety.md
View File

@ -117,7 +117,7 @@ The other pipelines don't get the protected variable. You can also
[scope variables to specific environments](../variables/where_variables_can_be_used.md#variables-with-an-environment-scope).
We recommend that you use protected variables on protected environments to make sure that the
secrets aren't exposed unintentionally. You can also define production secrets on the
[runner side](../runners/README.md#prevent-runners-from-revealing-sensitive-information).
[runner side](../runners/configure_runners.md#prevent-runners-from-revealing-sensitive-information).
This prevents other maintainers from reading the secrets and makes sure that the runner only runs on
protected branches.

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

@ -409,7 +409,7 @@ The job with [`action: stop` might not run](#the-job-with-action-stop-doesnt-run
if it's in a later stage than the job that started the environment.
If you can't use [pipelines for merge requests](../merge_request_pipelines/index.md),
set the [`GIT_STRATEGY`](../runners/README.md#git-strategy) to `none` in the
set the [`GIT_STRATEGY`](../runners/configure_runners.md#git-strategy) to `none` in the
`stop_review` job. Then the [runner](https://docs.gitlab.com/runner/) doesn't
try to check out the code after the branch is deleted.

2
doc/ci/environments/protected_environments.md
View File

@ -215,7 +215,7 @@ configured:
(or above) to the top-level group. They can maintain CI/CD configurations for
the higher environments (such as production) in the group-level settings page,
wnich includes group-level protected environments,
[group-level runners](../runners/README.md#group-runners),
[group-level runners](../runners/runners_scope.md#group-runners),
[group-level clusters](../../user/group/clusters/index.md), etc. Those
configurations are inherited to the child projects as read-only entries.
This ensures that only operators can configure the organization-wide

2
doc/ci/git_submodules.md
View File

@ -53,7 +53,7 @@ To make submodules work correctly in CI/CD jobs:
1. Make sure you use [relative URLs](#configure-the-gitmodules-file)
for submodules located in the same GitLab server.
1. You can set the `GIT_SUBMODULE_STRATEGY` variable to either `normal` or `recursive`
to tell the runner to [fetch your submodules before the job](runners/README.md#git-submodule-strategy):
to tell the runner to [fetch your submodules before the job](runners/configure_runners.md#git-submodule-strategy):
```yaml
variables:

2
doc/ci/interactive_web_terminal/index.md
View File

@ -16,7 +16,7 @@ is deployed, some [security precautions](../../administration/integration/termin
taken to protect the users.
NOTE:
[Shared runners on GitLab.com](../runners/README.md#shared-runners) do not
[Shared runners on GitLab.com](../runners/README.md) do not
provide an interactive web terminal. Follow [this
issue](https://gitlab.com/gitlab-org/gitlab/-/issues/24674) for progress on
adding support. For groups and projects hosted on GitLab.com, interactive web

16
doc/ci/large_repositories/index.md
View File

@ -56,7 +56,7 @@ test:
> Introduced in GitLab Runner 8.9.
By default, GitLab is configured to use the [`fetch` Git strategy](../runners/README.md#git-strategy),
By default, GitLab is configured to use the [`fetch` Git strategy](../runners/configure_runners.md#git-strategy),
which is recommended for large repositories.
This strategy reduces the amount of data to transfer and
does not really impact the operations that you might do on a repository from CI.
@ -65,7 +65,7 @@ does not really impact the operations that you might do on a repository from CI.
> Introduced in GitLab Runner 11.10.
[`GIT_CLONE_PATH`](../runners/README.md#custom-build-directories) allows you to
[`GIT_CLONE_PATH`](../runners/configure_runners.md#custom-build-directories) allows you to
control where you clone your sources. This can have implications if you
heavily use big repositories with fork workflow.
@ -77,7 +77,7 @@ In such cases, ideally you want to make the GitLab Runner executor be used only
for the given project and not shared across different projects to make this
process more efficient.
The [`GIT_CLONE_PATH`](../runners/README.md#custom-build-directories) has to be
The [`GIT_CLONE_PATH`](../runners/configure_runners.md#custom-build-directories) has to be
within the `$CI_BUILDS_DIR`. Currently, it is impossible to pick any path
from disk.
@ -85,12 +85,12 @@ from disk.
> Introduced in GitLab Runner 11.10.
[`GIT_CLEAN_FLAGS`](../runners/README.md#git-clean-flags) allows you to control
[`GIT_CLEAN_FLAGS`](../runners/configure_runners.md#git-clean-flags) allows you to control
whether or not you require the `git clean` command to be executed for each CI
job. By default, GitLab ensures that you have your worktree on the given SHA,
and that your repository is clean.
[`GIT_CLEAN_FLAGS`](../runners/README.md#git-clean-flags) is disabled when set
[`GIT_CLEAN_FLAGS`](../runners/configure_runners.md#git-clean-flags) is disabled when set
to `none`. On very big repositories, this might be desired because `git
clean` is disk I/O intensive. Controlling that with `GIT_CLEAN_FLAGS: -ffdx
-e .build/` (for example) allows you to control and disable removal of some
@ -99,7 +99,7 @@ the incremental builds. This has the biggest effect if you re-use existing
machines and have an existing worktree that you can re-use for builds.
For exact parameters accepted by
[`GIT_CLEAN_FLAGS`](../runners/README.md#git-clean-flags), see the documentation
[`GIT_CLEAN_FLAGS`](../runners/configure_runners.md#git-clean-flags), see the documentation
for [`git clean`](https://git-scm.com/docs/git-clean). The available parameters
are dependent on Git version.
@ -107,7 +107,7 @@ are dependent on Git version.
> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4142) in GitLab Runner 13.1.
[`GIT_FETCH_EXTRA_FLAGS`](../runners/README.md#git-fetch-extra-flags) allows you
[`GIT_FETCH_EXTRA_FLAGS`](../runners/configure_runners.md#git-fetch-extra-flags) allows you
to modify `git fetch` behavior by passing extra flags.
For example, if your project contains a large number of tags that your CI jobs don't rely on,
@ -119,7 +119,7 @@ tags, `--no-tags` can [make a big difference in some
cases](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/746).
If your CI builds do not depend on Git tags it is worth trying.
See the [`GIT_FETCH_EXTRA_FLAGS` documentation](../runners/README.md#git-fetch-extra-flags)
See the [`GIT_FETCH_EXTRA_FLAGS` documentation](../runners/configure_runners.md#git-fetch-extra-flags)
for more information.
## Fork-based workflow

8
doc/ci/migration/jenkins.md
View File

@ -128,16 +128,16 @@ agents you were using.
There are some important differences in the way runners work in comparison to agents:
- Runners can be set up as [shared across an instance, be added at the group level, or set up at the project level](../runners/README.md#types-of-runners).
- Runners can be set up as [shared across an instance, be added at the group level, or set up at the project level](../runners/runners_scope.md).
They self-select jobs from the scopes you've defined automatically.
- You can also [use tags](../runners/README.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) for finer control, and
- You can also [use tags](../runners/configure_runners.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) for finer control, and
associate runners with specific jobs. For example, you can use a tag for jobs that
require dedicated, more powerful, or specific hardware.
- GitLab has [autoscaling for runners](https://docs.gitlab.com/runner/configuration/autoscale.html).
Use autoscaling to provision runners only when needed, and scale down when not needed.
This is similar to ephemeral agents in Jenkins.
If you are using `gitlab.com`, you can take advantage of our [shared runner fleet](../../user/gitlab_com/index.md#shared-runners)
If you are using `gitlab.com`, you can take advantage of our [shared runner fleet](../runners/README.md)
to run jobs without provisioning your own runners. We are investigating making them
[available for self-managed instances](https://gitlab.com/groups/gitlab-org/-/epics/835)
as well.
@ -230,7 +230,7 @@ and is meant to be a mapping of concepts there to concepts in GitLab.
The agent section is used to define how a pipeline executes. For GitLab, we use [runners](../runners/README.md)
to provide this capability. You can configure your own runners in Kubernetes or on any host, or take advantage
of our shared runner fleet (note that the shared runner fleet is only available for GitLab.com users).
We also support using [tags](../runners/README.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) to direct different jobs
We also support using [tags](../runners/configure_runners.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) to direct different jobs
to different runners (execution agents).
The `agent` section also allows you to define which Docker images should be used for execution, for which we use

4
doc/ci/pipelines/settings.md
View File

@ -35,7 +35,7 @@ There are two options. Using:
back to clone if it doesn't exist).
This is recommended, especially for [large repositories](../large_repositories/index.md#git-strategy).
The configured Git strategy can be overridden by the [`GIT_STRATEGY` variable](../runners/README.md#git-strategy)
The configured Git strategy can be overridden by the [`GIT_STRATEGY` variable](../runners/configure_runners.md#git-strategy)
in `.gitlab-ci.yml`.
## Git shallow clone
@ -66,7 +66,7 @@ if the job surpasses the threshold, it is marked as failed.
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17221) in GitLab 10.7.
Project defined timeout (either specific timeout set by user or the default
60 minutes timeout) may be [overridden for runners](../runners/README.md#set-maximum-job-timeout-for-a-runner).
60 minutes timeout) may be [overridden for runners](../runners/configure_runners.md#set-maximum-job-timeout-for-a-runner).
## Maximum artifacts size **(FREE SELF)**

2
doc/ci/quick_start/index.md
View File

@ -41,7 +41,7 @@ The job results [are displayed in a pipeline](#view-the-status-of-your-pipeline-
In GitLab, runners are agents that run your CI/CD jobs.
You might already have runners available for your project, including
[shared runners](../runners/README.md#shared-runners), which are
[shared runners](../runners/runners_scope.md), which are
available to all projects in your GitLab instance.
To view available runners:

1013
doc/ci/runners/README.md
View File

File diff suppressed because it is too large Load Diff

600
doc/ci/runners/configure_runners.md Normal file
View File

@ -0,0 +1,600 @@
---
stage: Verify
group: Runner
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
type: reference
---
# Configuring runners
If you have installed your own runners, you can configure and secure them in GitLab.
If you need to configure runners on the machine where you installed GitLab Runner, see
[the GitLab Runner documentation](https://docs.gitlab.com/runner/configuration).
## Manually clear the runner cache
Read [clearing the cache](../caching/index.md#clearing-the-cache).
## Set maximum job timeout for a runner
For each runner, you can specify a *maximum job timeout*. This timeout,
if smaller than the [project defined timeout](../pipelines/settings.md#timeout), takes precedence.
This feature can be used to prevent your shared runner from being overwhelmed
by a project that has jobs with a long timeout (for example, one week).
When not configured, runners do not override the project timeout.
On GitLab.com, you cannot override the job timeout for shared runners and must use the [project defined timeout](../pipelines/settings.md#timeout).
To set the maximum job timeout:
1. In a project, go to **Settings > CI/CD > Runners**.
1. Select your specific runner to edit the settings.
1. Enter a value under **Maximum job timeout**.
1. Select **Save changes**.
How this feature works:
**Example 1 - Runner timeout bigger than project timeout**
1. You set the _maximum job timeout_ for a runner to 24 hours
1. You set the _CI/CD Timeout_ for a project to **2 hours**
1. You start a job
1. The job, if running longer, times out after **2 hours**
**Example 2 - Runner timeout not configured**
1. You remove the _maximum job timeout_ configuration from a runner
1. You set the _CI/CD Timeout_ for a project to **2 hours**
1. You start a job
1. The job, if running longer, times out after **2 hours**
**Example 3 - Runner timeout smaller than project timeout**
1. You set the _maximum job timeout_ for a runner to **30 minutes**
1. You set the _CI/CD Timeout_ for a project to 2 hours
1. You start a job
1. The job, if running longer, times out after **30 minutes**
## Be careful with sensitive information
With some [runner executors](https://docs.gitlab.com/runner/executors/README.html),
if you can run a job on the runner, you can get full access to the file system,
and thus any code it runs as well as the token of the runner. With shared runners, this means that anyone
that runs jobs on the runner, can access anyone else's code that runs on the
runner.
In addition, because you can get access to the runner token, it is possible
to create a clone of a runner and submit false jobs, for example.
The above is easily avoided by restricting the usage of shared runners
on large public GitLab instances, controlling access to your GitLab instance,
and using more secure [runner executors](https://docs.gitlab.com/runner/executors/README.html).
### Prevent runners from revealing sensitive information
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/13194) in GitLab 10.0.
You can protect runners so they don't reveal sensitive information.
When a runner is protected, the runner picks jobs created on
[protected branches](../../user/project/protected_branches.md) or [protected tags](../../user/project/protected_tags.md) only,
and ignores other jobs.
To protect or unprotect a runner:
1. Go to the project's **Settings > CI/CD** and expand the **Runners** section.
1. Find the runner you want to protect or unprotect. Make sure it's enabled.
1. Click the pencil button.
1. Check the **Protected** option.
1. Click **Save changes**.
![specific runners edit icon](img/protected_runners_check_box.png)
### Forks
Whenever a project is forked, it copies the settings of the jobs that relate
to it. This means that if you have shared runners set up for a project and
someone forks that project, the shared runners serve jobs of this project.
### Attack vectors in runners
Mentioned briefly earlier, but the following things of runners can be exploited.
We're always looking for contributions that can mitigate these
[Security Considerations](https://docs.gitlab.com/runner/security/).
### Reset the runner registration token for a project
If you think that a registration token for a project was revealed, you should
reset it. A token can be used to register another runner for the project. That new runner
may then be used to obtain the values of secret variables or to clone project code.
To reset the token:
1. Go to the project's **Settings > CI/CD**.
1. Expand the **General pipelines settings** section.
1. Find the **Runner token** form field and click the **Reveal value** button.
1. Delete the value and save the form.
1. After the page is refreshed, expand the **Runners settings** section
and check the registration token - it should be changed.
From now on the old token is no longer valid and does not register
any new runners to the project. If you are using any tools to provision and
register new runners, the tokens used in those tools should be updated to reflect the
value of the new token.
## Determine the IP address of a runner
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17286) in GitLab 10.6.
It may be useful to know the IP address of a runner so you can troubleshoot
issues with that runner. GitLab stores and displays the IP address by viewing
the source of the HTTP requests it makes to GitLab when polling for jobs. The
IP address is always kept up to date so if the runner IP changes it
automatically updates in GitLab.
The IP address for shared runners and specific runners can be found in
different places.
### Determine the IP address of a shared runner
To view the IP address of a shared runner you must have admin access to
the GitLab instance. To determine this:
1. Visit **Admin Area > Overview > Runners**.
1. Look for the runner in the table and you should see a column for **IP Address**.
![shared runner IP address](img/shared_runner_ip_address.png)
### Determine the IP address of a specific runner
To can find the IP address of a runner for a specific project,
you must have the [Owner role](../../user/permissions.md#project-members-permissions) for the
project.
1. Go to the project's **Settings > CI/CD** and expand the **Runners** section.
1. On the details page you should see a row for **IP Address**.
![specific runner IP address](img/specific_runner_ip_address.png)
## Use tags to limit the number of jobs using the runner
You must set up a runner to be able to run all the different types of jobs
that it may encounter on the projects it's shared over. This would be
problematic for large amounts of projects, if it weren't for tags.
GitLab CI tags are not the same as Git tags. GitLab CI tags are associated with runners.
Git tags are associated with commits.
By tagging a runner for the types of jobs it can handle, you can make sure
shared runners will [only run the jobs they are equipped to run](../yaml/README.md#tags).
For instance, at GitLab we have runners tagged with `rails` if they contain
the appropriate dependencies to run Rails test suites.
When you [register a runner](https://docs.gitlab.com/runner/register/), its default behavior is to **only pick**
[tagged jobs](../yaml/README.md#tags).
To change this, you must have the [Owner role](../../user/permissions.md#project-members-permissions) for the project.
To make a runner pick untagged jobs:
1. Go to the project's **Settings > CI/CD** and expand the **Runners** section.
1. Find the runner you want to pick untagged jobs and make sure it's enabled.
1. Click the pencil button.
1. Check the **Run untagged jobs** option.
1. Click the **Save changes** button for the changes to take effect.
NOTE:
The runner tags list can not be empty when it's not allowed to pick untagged jobs.
Below are some example scenarios of different variations.
### runner runs only tagged jobs
The following examples illustrate the potential impact of the runner being set
to run only tagged jobs.
Example 1:
1. The runner is configured to run only tagged jobs and has the `docker` tag.
1. A job that has a `hello` tag is executed and stuck.
Example 2:
1. The runner is configured to run only tagged jobs and has the `docker` tag.
1. A job that has a `docker` tag is executed and run.
Example 3:
1. The runner is configured to run only tagged jobs and has the `docker` tag.
1. A job that has no tags defined is executed and stuck.
### runner is allowed to run untagged jobs
The following examples illustrate the potential impact of the runner being set
to run tagged and untagged jobs.
Example 1:
1. The runner is configured to run untagged jobs and has the `docker` tag.
1. A job that has no tags defined is executed and run.
1. A second job that has a `docker` tag defined is executed and run.
Example 2:
1. The runner is configured to run untagged jobs and has no tags defined.
1. A job that has no tags defined is executed and run.
1. A second job that has a `docker` tag defined is stuck.
## Configure runner behavior with variables
You can use [CI/CD variables](../variables/README.md) to configure runner Git behavior
globally or for individual jobs:
- [`GIT_STRATEGY`](#git-strategy)
- [`GIT_SUBMODULE_STRATEGY`](#git-submodule-strategy)
- [`GIT_CHECKOUT`](#git-checkout)
- [`GIT_CLEAN_FLAGS`](#git-clean-flags)
- [`GIT_FETCH_EXTRA_FLAGS`](#git-fetch-extra-flags)
- [`GIT_DEPTH`](#shallow-cloning) (shallow cloning)
- [`GIT_CLONE_PATH`](#custom-build-directories) (custom build directories)
You can also use variables to configure how many times a runner
[attempts certain stages of job execution](#job-stages-attempts).
### Git strategy
> - Introduced in GitLab 8.9 as an experimental feature.
> - `GIT_STRATEGY=none` requires GitLab Runner v1.7+.
You can set the `GIT_STRATEGY` used to fetch the repository content, either
globally or per-job in the [`variables`](../yaml/README.md#variables) section:
```yaml
variables:
GIT_STRATEGY: clone
```
There are three possible values: `clone`, `fetch`, and `none`. If left unspecified,
jobs use the [project's pipeline setting](../pipelines/settings.md#git-strategy).
`clone` is the slowest option. It clones the repository from scratch for every
job, ensuring that the local working copy is always pristine.
If an existing worktree is found, it is removed before cloning.
`fetch` is faster as it re-uses the local working copy (falling back to `clone`
if it does not exist). `git clean` is used to undo any changes made by the last
job, and `git fetch` is used to retrieve commits made after the last job ran.
However, `fetch` does require access to the previous worktree. This works
well when using the `shell` or `docker` executor because these
try to preserve worktrees and try to re-use them by default.
This has limitations when using the [Docker Machine executor](https://docs.gitlab.com/runner/executors/docker_machine.html).
It does not work for [the `kubernetes` executor](https://docs.gitlab.com/runner/executors/kubernetes.html),
but a [feature proposal](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3847) exists.
The `kubernetes` executor always clones into an temporary directory.
A Git strategy of `none` also re-uses the local working copy, but skips all Git
operations normally done by GitLab. GitLab Runner pre-clone scripts are also skipped,
if present. This strategy could mean you need to add `fetch` and `checkout` commands
to [your `.gitlab-ci.yml` script](../yaml/README.md#script).
It can be used for jobs that operate exclusively on artifacts, like a deployment job.
Git repository data may be present, but it's likely out of date. You should only
rely on files brought into the local working copy from cache or artifacts.
### Git submodule strategy
> Requires GitLab Runner v1.10+.
The `GIT_SUBMODULE_STRATEGY` variable is used to control if / how Git
submodules are included when fetching the code before a build. You can set them
globally or per-job in the [`variables`](../yaml/README.md#variables) section.
There are three possible values: `none`, `normal`, and `recursive`:
- `none` means that submodules are not included when fetching the project
code. This is the default, which matches the pre-v1.10 behavior.
- `normal` means that only the top-level submodules are included. It's
equivalent to:
```shell
git submodule sync
git submodule update --init
```
- `recursive` means that all submodules (including submodules of submodules)
are included. This feature needs Git v1.8.1 and later. When using a
GitLab Runner with an executor not based on Docker, make sure the Git version
meets that requirement. It's equivalent to:
```shell
git submodule sync --recursive
git submodule update --init --recursive
```
For this feature to work correctly, the submodules must be configured
(in `.gitmodules`) with either:
- the HTTP(S) URL of a publicly-accessible repository, or
- a relative path to another repository on the same GitLab server. See the
[Git submodules](../git_submodules.md) documentation.
### Git checkout
> Introduced in GitLab Runner 9.3.
The `GIT_CHECKOUT` variable can be used when the `GIT_STRATEGY` is set to either
`clone` or `fetch` to specify whether a `git checkout` should be run. If not
specified, it defaults to true. You can set them globally or per-job in the
[`variables`](../yaml/README.md#variables) section.
If set to `false`, the runner:
- when doing `fetch` - updates the repository and leaves the working copy on
the current revision,
- when doing `clone` - clones the repository and leaves the working copy on the
default branch.
If `GIT_CHECKOUT` is set to `true`, both `clone` and `fetch` work the same way.
The runner checks out the working copy of a revision related
to the CI pipeline:
```yaml
variables:
GIT_STRATEGY: clone
GIT_CHECKOUT: "false"
script:
- git checkout -B master origin/master
- git merge $CI_COMMIT_SHA
```
### Git clean flags
> Introduced in GitLab Runner 11.10
The `GIT_CLEAN_FLAGS` variable is used to control the default behavior of
`git clean` after checking out the sources. You can set it globally or per-job in the
[`variables`](../yaml/README.md#variables) section.
`GIT_CLEAN_FLAGS` accepts all possible options of the [`git clean`](https://git-scm.com/docs/git-clean)
command.
`git clean` is disabled if `GIT_CHECKOUT: "false"` is specified.
If `GIT_CLEAN_FLAGS` is:
- Not specified, `git clean` flags default to `-ffdx`.
- Given the value `none`, `git clean` is not executed.
For example:
```yaml
variables:
GIT_CLEAN_FLAGS: -ffdx -e cache/
script:
- ls -al cache/
```
### Git fetch extra flags
> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4142) in GitLab Runner 13.1.
The `GIT_FETCH_EXTRA_FLAGS` variable is used to control the behavior of
`git fetch`. You can set it globally or per-job in the [`variables`](../yaml/README.md#variables) section.
`GIT_FETCH_EXTRA_FLAGS` accepts all options of the [`git fetch`](https://git-scm.com/docs/git-fetch) command. However, `GIT_FETCH_EXTRA_FLAGS` flags are appended after the default flags that can't be modified.
The default flags are:
- [GIT_DEPTH](#shallow-cloning).
- The list of [refspecs](https://git-scm.com/book/en/v2/Git-Internals-The-Refspec).
- A remote called `origin`.
If `GIT_FETCH_EXTRA_FLAGS` is:
- Not specified, `git fetch` flags default to `--prune --quiet` along with the default flags.
- Given the value `none`, `git fetch` is executed only with the default flags.
For example, the default flags are `--prune --quiet`, so you can make `git fetch` more verbose by overriding this with just `--prune`:
```yaml
variables:
GIT_FETCH_EXTRA_FLAGS: --prune
script:
- ls -al cache/
```
The configuration above results in `git fetch` being called this way:
```shell
git fetch origin $REFSPECS --depth 50 --prune
```
Where `$REFSPECS` is a value provided to the runner internally by GitLab.
### Shallow cloning
> Introduced in GitLab 8.9 as an experimental feature.
You can specify the depth of fetching and cloning using `GIT_DEPTH`.
`GIT_DEPTH` does a shallow clone of the repository and can significantly speed up cloning.
It can be helpful for repositories with a large number of commits or old, large binaries. The value is
passed to `git fetch` and `git clone`.
In GitLab 12.0 and later, newly-created projects automatically have a
[default `git depth` value of `50`](../pipelines/settings.md#git-shallow-clone).
If you use a depth of `1` and have a queue of jobs or retry
jobs, jobs may fail.
Git fetching and cloning is based on a ref, such as a branch name, so runners
can't clone a specific commit SHA. If multiple jobs are in the queue, or
you're retrying an old job, the commit to be tested must be within the
Git history that is cloned. Setting too small a value for `GIT_DEPTH` can make
it impossible to run these old commits and `unresolved reference` is displayed in
job logs. You should then reconsider changing `GIT_DEPTH` to a higher value.
Jobs that rely on `git describe` may not work correctly when `GIT_DEPTH` is
set since only part of the Git history is present.
To fetch or clone only the last 3 commits:
```yaml
variables:
GIT_DEPTH: "3"
```
You can set it globally or per-job in the [`variables`](../yaml/README.md#variables) section.
### Custom build directories
> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2211) in GitLab Runner 11.10.
By default, GitLab Runner clones the repository in a unique subpath of the
`$CI_BUILDS_DIR` directory. However, your project might require the code in a
specific directory (Go projects, for example). In that case, you can specify
the `GIT_CLONE_PATH` variable to tell the runner the directory to clone the
repository in:
```yaml
variables:
GIT_CLONE_PATH: $CI_BUILDS_DIR/project-name
test:
script:
- pwd
```
The `GIT_CLONE_PATH` has to always be within `$CI_BUILDS_DIR`. The directory set in `$CI_BUILDS_DIR`
is dependent on executor and configuration of [runners.builds_dir](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section)
setting.
This can only be used when `custom_build_dir` is enabled in the
[runner's configuration](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnerscustom_build_dir-section).
This is the default configuration for the `docker` and `kubernetes` executors.
#### Handling concurrency
An executor that uses a concurrency greater than `1` might lead
to failures. Multiple jobs might be working on the same directory if the `builds_dir`
is shared between jobs.
The runner does not try to prevent this situation. It's up to the administrator
and developers to comply with the requirements of runner configuration.
To avoid this scenario, you can use a unique path within `$CI_BUILDS_DIR`, because runner
exposes two additional variables that provide a unique `ID` of concurrency:
- `$CI_CONCURRENT_ID`: Unique ID for all jobs running within the given executor.
- `$CI_CONCURRENT_PROJECT_ID`: Unique ID for all jobs running within the given executor and project.
The most stable configuration that should work well in any scenario and on any executor
is to use `$CI_CONCURRENT_ID` in the `GIT_CLONE_PATH`. For example:
```yaml
variables:
GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/project-name
test:
script:
- pwd
```
The `$CI_CONCURRENT_PROJECT_ID` should be used in conjunction with `$CI_PROJECT_PATH`
as the `$CI_PROJECT_PATH` provides a path of a repository. That is, `group/subgroup/project`. For example:
```yaml
variables:
GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/$CI_PROJECT_PATH
test:
script:
- pwd
```
#### Nested paths
The value of `GIT_CLONE_PATH` is expanded once and nesting variables
within is not supported.
For example, you define both the variables below in your
`.gitlab-ci.yml` file:
```yaml
variables:
GOPATH: $CI_BUILDS_DIR/go
GIT_CLONE_PATH: $GOPATH/src/namespace/project
```
The value of `GIT_CLONE_PATH` is expanded once into
`$CI_BUILDS_DIR/go/src/namespace/project`, and results in failure
because `$CI_BUILDS_DIR` is not expanded.
### Job stages attempts
> Introduced in GitLab, it requires GitLab Runner v1.9+.
You can set the number of attempts that the running job tries to execute
the following stages:
| Variable | Description |
|---------------------------------|--------------------------------------------------------|
| `ARTIFACT_DOWNLOAD_ATTEMPTS` | Number of attempts to download artifacts running a job |
| `EXECUTOR_JOB_SECTION_ATTEMPTS` | [In GitLab 12.10](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4450) and later, the number of attempts to run a section in a job after a [`No Such Container`](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4450) error ([Docker executor](https://docs.gitlab.com/runner/executors/docker.html) only). |
| `GET_SOURCES_ATTEMPTS` | Number of attempts to fetch sources running a job |
| `RESTORE_CACHE_ATTEMPTS` | Number of attempts to restore the cache running a job |
The default is one single attempt.
Example:
```yaml
variables:
GET_SOURCES_ATTEMPTS: 3
```
You can set them globally or per-job in the [`variables`](../yaml/README.md#variables) section.
## System calls not available on GitLab.com shared runners
GitLab.com shared runners run on CoreOS. This means that you cannot use some system calls, like `getlogin`, from the C standard library.
## Artifact and cache settings
> Introduced in GitLab Runner 13.9.
Artifact and cache settings control the compression ratio of artifacts and caches.
Use these settings to specify the size of the archive produced by a job.
- On a slow network, uploads might be faster for smaller archives.
- On a fast network where bandwidth and storage are not a concern, uploads might be faster using the fastest compression ratio, despite the archive produced being larger.
For [GitLab Pages](../../user/project/pages/index.md) to serve
[HTTP Range requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests), artifacts
should use the `ARTIFACT_COMPRESSION_LEVEL: fastest` setting, as only uncompressed zip archives
support this feature.
A meter can also be enabled to provide the rate of transfer for uploads and downloads.
```yaml
variables:
# output upload and download progress every 2 seconds
TRANSFER_METER_FREQUENCY: "2s"
# Use fast compression for artifacts, resulting in larger archives
ARTIFACT_COMPRESSION_LEVEL: "fast"
# Use no compression for caches
CACHE_COMPRESSION_LEVEL: "fastest"
```
| Variable | Description |
|---------------------------------|--------------------------------------------------------|
| `TRANSFER_METER_FREQUENCY` | Specify how often to print the meter's transfer rate. It can be set to a duration (for example, `1s` or `1m30s`). A duration of `0` disables the meter (default). When a value is set, the pipeline shows a progress meter for artifact and cache uploads and downloads. |
| `ARTIFACT_COMPRESSION_LEVEL` | To adjust compression ratio, set to `fastest`, `fast`, `default`, `slow`, or `slowest`. This setting works with the Fastzip archiver only, so the GitLab Runner feature flag [`FF_USE_FASTZIP`](https://docs.gitlab.com/runner/configuration/feature-flags.html#available-feature-flags) must also be enabled. |
| `CACHE_COMPRESSION_LEVEL` | To adjust compression ratio, set to `fastest`, `fast`, `default`, `slow`, or `slowest`. This setting works with the Fastzip archiver only, so the GitLab Runner feature flag [`FF_USE_FASTZIP`](https://docs.gitlab.com/runner/configuration/feature-flags.html#available-feature-flags) must also be enabled. |

251
doc/ci/runners/runners_scope.md Normal file
View File

@ -0,0 +1,251 @@
---
stage: Verify
group: Runner
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
type: reference
---
# The scope of runners
Runners are available based on who you want to have access:
- [Shared runners](#shared-runners) are available to all groups and projects in a GitLab instance.
- [Group runners](#group-runners) are available to all projects and subgroups in a group.
- [Specific runners](#specific-runners) are associated with specific projects.
Typically, specific runners are used for one project at a time.
## Shared runners
*Shared runners* are available to every project in a GitLab instance.
Use shared runners when you have multiple jobs with similar requirements. Rather than
having multiple runners idling for many projects, you can have a few runners that handle
multiple projects.
If you are using a self-managed instance of GitLab:
- Your administrator can install and register shared runners by
going to your project's **Settings > CI/CD**, expanding the **Runners** section,
and clicking **Show runner installation instructions**.
These instructions are also available [in the documentation](https://docs.gitlab.com/runner/install/index.html).
- The administrator can also configure a maximum number of shared runner [pipeline minutes for
each group](../../user/admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota).
If you are using GitLab.com:
- You can select from a list of [shared runners that GitLab maintains](../../user/gitlab_com/index.md#shared-runners).
- The shared runners consume the [pipelines minutes](../../subscriptions/gitlab_com/index.md#ci-pipeline-minutes)
included with your account.
### Enable shared runners
On GitLab.com, [shared runners](#shared-runners) are enabled in all projects by
default.
On self-managed instances of GitLab, an administrator must [install](https://docs.gitlab.com/runner/install/index.html)
and [register](https://docs.gitlab.com/runner/register/index.html) them.
You can also enable shared runners for individual projects.
To enable shared runners:
1. Go to the project's **Settings > CI/CD** and expand the **Runners** section.
1. Select **Enable shared runners for this project**.
### Disable shared runners
You can disable shared runners for individual projects or for groups.
You must have the [Owner role](../../user/permissions.md#group-members-permissions) for the project
or group.
To disable shared runners for a project:
1. Go to the project's **Settings > CI/CD** and expand the **Runners** section.
1. In the **Shared runners** area, select **Enable shared runners for this project** so the toggle is grayed-out.
Shared runners are automatically disabled for a project:
- If the shared runners setting for the parent group is disabled, and
- If overriding this setting is not permitted at the project level.
To disable shared runners for a group:
1. Go to the group's **Settings > CI/CD** and expand the **Runners** section.
1. In the **Shared runners** area, turn off the **Enable shared runners for this group** toggle.
1. Optionally, to allow shared runners to be enabled for individual projects or subgroups,
click **Allow projects and subgroups to override the group setting**.
NOTE:
To re-enable the shared runners for a group, turn on the
**Enable shared runners for this group** toggle.
Then, an owner or maintainer must explicitly change this setting
for each project subgroup or project.
### How shared runners pick jobs
Shared runners process jobs by using a fair usage queue. This queue prevents
projects from creating hundreds of jobs and using all available
shared runner resources.
The fair usage queue algorithm assigns jobs based on the projects that have the
fewest number of jobs already running on shared runners.
**Example 1**
If these jobs are in the queue:
- Job 1 for Project 1
- Job 2 for Project 1
- Job 3 for Project 1
- Job 4 for Project 2
- Job 5 for Project 2
- Job 6 for Project 3
The fair usage algorithm assigns jobs in this order:
1. Job 1 is first, because it has the lowest job number from projects with no running jobs (that is, all projects).
1. Job 4 is next, because 4 is now the lowest job number from projects with no running jobs (Project 1 has a job running).
1. Job 6 is next, because 6 is now the lowest job number from projects with no running jobs (Projects 1 and 2 have jobs running).
1. Job 2 is next, because, of projects with the lowest number of jobs running (each has 1), it is the lowest job number.
1. Job 5 is next, because Project 1 now has 2 jobs running and Job 5 is the lowest remaining job number between Projects 2 and 3.
1. Finally is Job 3... because it's the only job left.
---
**Example 2**
If these jobs are in the queue:
- Job 1 for Project 1
- Job 2 for Project 1
- Job 3 for Project 1
- Job 4 for Project 2
- Job 5 for Project 2
- Job 6 for Project 3
The fair usage algorithm assigns jobs in this order:
1. Job 1 is chosen first, because it has the lowest job number from projects with no running jobs (that is, all projects).
1. We finish Job 1.
1. Job 2 is next, because, having finished Job 1, all projects have 0 jobs running again, and 2 is the lowest available job number.
1. Job 4 is next, because with Project 1 running a Job, 4 is the lowest number from projects running no jobs (Projects 2 and 3).
1. We finish Job 4.
1. Job 5 is next, because having finished Job 4, Project 2 has no jobs running again.
1. Job 6 is next, because Project 3 is the only project left with no running jobs.
1. Lastly we choose Job 3... because, again, it's the only job left.
## Group runners
Use *Group runners* when you want all projects in a group
to have access to a set of runners.
Group runners process jobs by using a first in, first out ([FIFO](https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics))) queue.
### Create a group runner
You can create a group runner for your self-managed GitLab instance or for GitLab.com.
You must have the [Owner role](../../user/permissions.md#group-members-permissions) for the group.
To create a group runner:
1. [Install GitLab Runner](https://docs.gitlab.com/runner/install/).
1. Go to the group you want to make the runner work for.
1. Go to **Settings > CI/CD** and expand the **Runners** section.
1. Note the URL and token.
1. [Register the runner](https://docs.gitlab.com/runner/register/).
### View and manage group runners
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/37366/) in GitLab 13.2.
You can view and manage all runners for a group, its subgroups, and projects.
You can do this for your self-managed GitLab instance or for GitLab.com.
You must have the [Owner role](../../user/permissions.md#group-members-permissions) for the group.
1. Go to the group where you want to view the runners.
1. Go to **Settings > CI/CD** and expand the **Runners** section.
1. The following fields are displayed.
| Attribute | Description |
| ------------ | ----------- |
| Type | Displays the runner type: `group` or `specific`, together with the optional states `locked` and `paused` |
| Runner token | Token used to identify the runner, and that the runner uses to communicate with the GitLab instance |
| Description | Description given to the runner when it was created |
| Version | GitLab Runner version |
| IP address | IP address of the host on which the runner is registered |
| Projects | The count of projects to which the runner is assigned |
| Jobs | Total of jobs run by the runner |
| Tags | Tags associated with the runner |
| Last contact | Timestamp indicating when the GitLab instance last contacted the runner |
From this page, you can edit, pause, and remove runners from the group, its subgroups, and projects.
### Pause or remove a group runner
You can pause or remove a group runner for your self-managed GitLab instance or for GitLab.com.
You must have the [Owner role](../../user/permissions.md#group-members-permissions) for the group.
1. Go to the group you want to remove or pause the runner for.
1. Go to **Settings > CI/CD** and expand the **Runners** section.
1. Click **Pause** or **Remove runner**.
- If you pause a group runner that is used by multiple projects, the runner pauses for all projects.
- From the group view, you cannot remove a runner that is assigned to more than one project.
You must remove it from each project first.
1. On the confirmation dialog, click **OK**.
## Specific runners
Use *Specific runners* when you want to use runners for specific projects. For example,
when you have:
- Jobs with specific requirements, like a deploy job that requires credentials.
- Projects with a lot of CI activity that can benefit from being separate from other runners.
You can set up a specific runner to be used by multiple projects. Specific runners
must be enabled for each project explicitly.
Specific runners process jobs by using a first in, first out ([FIFO](https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics))) queue.
NOTE:
Specific runners do not get shared with forked projects automatically.
A fork *does* copy the CI/CD settings of the cloned repository.
### Create a specific runner
You can create a specific runner for your self-managed GitLab instance or for GitLab.com.
You must have the [Owner role](../../user/permissions.md#project-members-permissions) for the project.
To create a specific runner:
1. [Install runner](https://docs.gitlab.com/runner/install/).
1. Go to the project's **Settings > CI/CD** and expand the **Runners** section.
1. Note the URL and token.
1. [Register the runner](https://docs.gitlab.com/runner/register/).
### Enable a specific runner for a specific project
A specific runner is available in the project it was created for. An administrator can
enable a specific runner to apply to additional projects.
- You must have the [Owner role](../../user/permissions.md#group-members-permissions) for the
project.
- The specific runner must not be [locked](#prevent-a-specific-runner-from-being-enabled-for-other-projects).
To enable or disable a specific runner for a project:
1. Go to the project's **Settings > CI/CD** and expand the **Runners** section.
1. Click **Enable for this project** or **Disable for this project**.
### Prevent a specific runner from being enabled for other projects
You can configure a specific runner so it is "locked" and cannot be enabled for other projects.
This setting can be enabled when you first [register a runner](https://docs.gitlab.com/runner/register/),
but can also be changed later.
To lock or unlock a runner:
1. Go to the project's **Settings > CI/CD** and expand the **Runners** section.
1. Find the runner you want to lock or unlock. Make sure it's enabled.
1. Click the pencil button.
1. Check the **Lock to current projects** option.
1. Click **Save changes**.

24
doc/ci/yaml/README.md
View File

@ -3740,7 +3740,7 @@ Possible values for `when` are:
- `scheduler_failure`: Retry if the scheduler failed to assign the job to a runner.
- `data_integrity_failure`: Retry if there is a structural integrity problem detected.
You can specify the number of [retry attempts for certain stages of job execution](../runners/README.md#job-stages-attempts) using variables.
You can specify the number of [retry attempts for certain stages of job execution](../runners/configure_runners.md#job-stages-attempts) using variables.
### `timeout`
@ -4801,19 +4801,19 @@ You cannot set job-level variables to be pre-filled when you run a pipeline manu
You can use [CI/CD variables](../variables/README.md) to configure how the runner processes Git requests:
- [`GIT_STRATEGY`](../runners/README.md#git-strategy)
- [`GIT_SUBMODULE_STRATEGY`](../runners/README.md#git-submodule-strategy)
- [`GIT_CHECKOUT`](../runners/README.md#git-checkout)
- [`GIT_CLEAN_FLAGS`](../runners/README.md#git-clean-flags)
- [`GIT_FETCH_EXTRA_FLAGS`](../runners/README.md#git-fetch-extra-flags)
- [`GIT_DEPTH`](../runners/README.md#shallow-cloning) (shallow cloning)
- [`GIT_CLONE_PATH`](../runners/README.md#custom-build-directories) (custom build directories)
- [`TRANSFER_METER_FREQUENCY`](../runners/README.md#artifact-and-cache-settings) (artifact/cache meter update frequency)
- [`ARTIFACT_COMPRESSION_LEVEL`](../runners/README.md#artifact-and-cache-settings) (artifact archiver compression level)
- [`CACHE_COMPRESSION_LEVEL`](../runners/README.md#artifact-and-cache-settings) (cache archiver compression level)
- [`GIT_STRATEGY`](../runners/configure_runners.md#git-strategy)
- [`GIT_SUBMODULE_STRATEGY`](../runners/configure_runners.md#git-submodule-strategy)
- [`GIT_CHECKOUT`](../runners/configure_runners.md#git-checkout)
- [`GIT_CLEAN_FLAGS`](../runners/configure_runners.md#git-clean-flags)
- [`GIT_FETCH_EXTRA_FLAGS`](../runners/configure_runners.md#git-fetch-extra-flags)
- [`GIT_DEPTH`](../runners/configure_runners.md#shallow-cloning) (shallow cloning)
- [`GIT_CLONE_PATH`](../runners/configure_runners.md#custom-build-directories) (custom build directories)
- [`TRANSFER_METER_FREQUENCY`](../runners/configure_runners.md#artifact-and-cache-settings) (artifact/cache meter update frequency)
- [`ARTIFACT_COMPRESSION_LEVEL`](../runners/configure_runners.md#artifact-and-cache-settings) (artifact archiver compression level)
- [`CACHE_COMPRESSION_LEVEL`](../runners/configure_runners.md#artifact-and-cache-settings) (cache archiver compression level)
You can also use variables to configure how many times a runner
[attempts certain stages of job execution](../runners/README.md#job-stages-attempts).
[attempts certain stages of job execution](../runners/configure_runners.md#job-stages-attempts).
## YAML-specific features

2
doc/development/documentation/index.md
View File

@ -478,7 +478,7 @@ The following GitLab features are used among others:
- [Multi project pipelines](../../ci/multi_project_pipelines.md)
- [Review Apps](../../ci/review_apps/index.md)
- [Artifacts](../../ci/yaml/README.md#artifacts)
- [Specific runner](../../ci/runners/README.md#prevent-a-specific-runner-from-being-enabled-for-other-projects)
- [Specific runner](../../ci/runners/runners_scope.md#prevent-a-specific-runner-from-being-enabled-for-other-projects)
- [Pipelines for merge requests](../../ci/merge_request_pipelines/index.md)
## Testing

2
doc/development/pipelines.md
View File

@ -583,7 +583,7 @@ several reasons:
- It significantly reduces load on the file server, as smaller deltas mean less time spent in `git pack-objects`.
The pre-clone step works by using the `CI_PRE_CLONE_SCRIPT` variable
[defined by GitLab.com shared runners](../user/gitlab_com/index.md#pre-clone-script).
[defined by GitLab.com shared runners](../ci/runners/README.md#pre-clone-script).
The `CI_PRE_CLONE_SCRIPT` is currently defined as a project CI/CD variable:

4
doc/topics/autodevops/requirements.md
View File

@ -64,8 +64,8 @@ To make full use of Auto DevOps with Kubernetes, you need:
You can configure Docker-based runners to autoscale as well, using
[Docker Machine](https://docs.gitlab.com/runner/install/autoscaling.html).
Runners should be registered as [shared runners](../../ci/runners/README.md#shared-runners)
for the entire GitLab instance, or [specific runners](../../ci/runners/README.md#specific-runners)
Runners should be registered as [shared runners](../../ci/runners/runners_scope.md#shared-runners)
for the entire GitLab instance, or [specific runners](../../ci/runners/runners_scope.md#specific-runners)
that are assigned to specific projects (the default if you've installed the
GitLab Runner managed application).

2
doc/user/application_security/container_scanning/index.md
View File

@ -571,7 +571,7 @@ automatically generates.
To enable remediation support, the scanning tool _must_ have access to the `Dockerfile` specified by
the [`DOCKERFILE_PATH`](#available-cicd-variables) CI/CD variable. To ensure that the scanning tool
has access to this
file, it's necessary to set [`GIT_STRATEGY: fetch`](../../../ci/runners/README.md#git-strategy) in
file, it's necessary to set [`GIT_STRATEGY: fetch`](../../../ci/runners/configure_runners.md#git-strategy) in
your `.gitlab-ci.yml` file by following the instructions described in this document's
[overriding the container scanning template](#overriding-the-container-scanning-template) section.

2
doc/user/application_security/dast/index.md
View File

@ -810,7 +810,7 @@ variables:
### Cloning the project's repository
The DAST job does not require the project's repository to be present when running, so by default
[`GIT_STRATEGY`](../../../ci/runners/README.md#git-strategy) is set to `none`.
[`GIT_STRATEGY`](../../../ci/runners/configure_runners.md#git-strategy) is set to `none`.
### Debugging DAST jobs

4
doc/user/application_security/secret_detection/index.md
View File

@ -177,7 +177,7 @@ is no longer supported. When overriding the template, you must use [`rules`](../
#### GIT_DEPTH
The [`GIT_DEPTH` CI/CD variable](../../../ci/runners/README.md#shallow-cloning) affects Secret Detection.
The [`GIT_DEPTH` CI/CD variable](../../../ci/runners/configure_runners.md#shallow-cloning) affects Secret Detection.
The Secret Detection analyzer relies on generating patches between commits to scan content for
secrets. If you override the default, ensure the value is greater than 1. If the number of commits
in an MR is greater than the GIT_DEPTH value, Secret Detection will [fail to detect secrets](#error-couldnt-run-the-gitleaks-command-exit-status-2).
@ -399,7 +399,7 @@ ERRO[2020-11-18T18:05:52Z] object not found
[ERRO] [secrets] [2020-11-18T18:05:52Z] ▶ Gitleaks analysis failed: exit status 2
```
To resolve the issue, set the [`GIT_DEPTH` CI/CD variable](../../../ci/runners/README.md#shallow-cloning)
To resolve the issue, set the [`GIT_DEPTH` CI/CD variable](../../../ci/runners/configure_runners.md#shallow-cloning)
to a higher value. To apply this only to the Secret Detection job, the following can be added to
your `.gitlab-ci.yml` file:

278
doc/user/gitlab_com/index.md
View File

@ -157,285 +157,13 @@ A limit of:
- 100 webhooks applies to projects.
- 50 webhooks applies to groups. **(BRONZE ONLY)**
- Payload is limited to 25MB
- Payload is limited to 25MB.
## Shared runners
GitLab offers Linux and Windows shared runners hosted on GitLab.com for executing your pipelines.
GitLab has shared runners on GitLab.com that you can use to run your CI jobs.
NOTE:
Shared runners provided by GitLab are **not** configurable. Consider [installing your own runner](https://docs.gitlab.com/runner/install/) if you have specific configuration needs.
### Linux shared runners
Linux shared runners on GitLab.com run in autoscale mode and are powered by Google Cloud Platform.
Autoscaling means reduced queue times to spin up CI/CD jobs, and isolated VMs for each project, thus maximizing security. These shared runners are available for users and customers on GitLab.com.
GitLab offers Ultimate tier capabilities and included CI/CD minutes per group per month for our [Open Source](https://about.gitlab.com/solutions/open-source/join/), [Education](https://about.gitlab.com/solutions/education/), and [Startups](https://about.gitlab.com/solutions/startups/) programs. For private projects, GitLab offers various [plans](https://about.gitlab.com/pricing/), starting with a Free tier.
All your CI/CD jobs run on [n1-standard-1 instances](https://cloud.google.com/compute/docs/machine-types) with 3.75GB of RAM, CoreOS and the latest Docker Engine
installed. Instances provide 1 vCPU and 25GB of HDD disk space. The default
region of the VMs is US East1.
Each instance is used only for one job, this ensures any sensitive data left on the system can't be accessed by other people their CI jobs.
The `gitlab-shared-runners-manager-X.gitlab.com` fleet of runners are dedicated for GitLab projects as well as community forks of them. They use a slightly larger machine type (n1-standard-2) and have a bigger SSD disk size. They don't run untagged jobs and unlike the general fleet of shared runners, the instances are re-used up to 40 times.
Jobs handled by the shared runners on GitLab.com (`shared-runners-manager-X.gitlab.com`),
**time out after 3 hours**, regardless of the timeout configured in a
project. Check the issues [4010](https://gitlab.com/gitlab-com/infrastructure/-/issues/4010) and [4070](https://gitlab.com/gitlab-com/infrastructure/-/issues/4070) for the reference.
Below are the shared runners settings.
| Setting | GitLab.com | Default |
| ----------- | ----------------- | ---------- |
| [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner) | [Runner versions dashboard](https://dashboards.gitlab.com/d/000000159/ci?from=now-1h&to=now&refresh=5m&orgId=1&panelId=12&fullscreen&theme=light) | - |
| Executor | `docker+machine` | - |
| Default Docker image | `ruby:2.5` | - |
| `privileged` (run [Docker in Docker](https://hub.docker.com/_/docker/)) | `true` | `false` |
#### Pre-clone script
Linux shared runners on GitLab.com provide a way to run commands in a CI
job before the runner attempts to run `git init` and `git fetch` to
download a GitLab repository. The
[`pre_clone_script`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section)
can be used for:
- Seeding the build directory with repository data
- Sending a request to a server
- Downloading assets from a CDN
- Any other commands that must run before the `git init`
To use this feature, define a [CI/CD variable](../../ci/variables/README.md#custom-cicd-variables) called
`CI_PRE_CLONE_SCRIPT` that contains a bash script.
[This example](../../development/pipelines.md#pre-clone-step)
demonstrates how you might use a pre-clone step to seed the build
directory.
#### `config.toml`
The full contents of our `config.toml` are:
NOTE:
Settings that are not public are shown as `X`.
**Google Cloud Platform**
```toml
concurrent = X
check_interval = 1
metrics_server = "X"
sentry_dsn = "X"
[[runners]]
name = "docker-auto-scale"
request_concurrency = X
url = "https://gitlab.com/"
token = "SHARED_RUNNER_TOKEN"
pre_clone_script = "eval \"$CI_PRE_CLONE_SCRIPT\""
executor = "docker+machine"
environment = [
"DOCKER_DRIVER=overlay2",
"DOCKER_TLS_CERTDIR="
]
limit = X
[runners.docker]
image = "ruby:2.5"
privileged = true
volumes = [
"/certs/client",
"/dummy-sys-class-dmi-id:/sys/class/dmi/id:ro" # Make kaniko builds work on GCP.
]
[runners.machine]
IdleCount = 50
IdleTime = 3600
MaxBuilds = 1 # For security reasons we delete the VM after job has finished so it's not reused.
MachineName = "srm-%s"
MachineDriver = "google"
MachineOptions = [
"google-project=PROJECT",
"google-disk-size=25",
"google-machine-type=n1-standard-1",
"google-username=core",
"google-tags=gitlab-com,srm",
"google-use-internal-ip",
"google-zone=us-east1-d",
"engine-opt=mtu=1460", # Set MTU for container interface, for more information check https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3214#note_82892928
"google-machine-image=PROJECT/global/images/IMAGE",
"engine-opt=ipv6", # This will create IPv6 interfaces in the containers.
"engine-opt=fixed-cidr-v6=fc00::/7",
"google-operation-backoff-initial-interval=2" # Custom flag from forked docker-machine, for more information check https://github.com/docker/machine/pull/4600
]
[[runners.machine.autoscaling]]
Periods = ["* * * * * sat,sun *"]
Timezone = "UTC"
IdleCount = 70
IdleTime = 3600
[[runners.machine.autoscaling]]
Periods = ["* 30-59 3 * * * *", "* 0-30 4 * * * *"]
Timezone = "UTC"
IdleCount = 700
IdleTime = 3600
[runners.cache]
Type = "gcs"
Shared = true
[runners.cache.gcs]
CredentialsFile = "/path/to/file"
BucketName = "bucket-name"
```
### Windows shared runners (beta)
The Windows shared runners are in [beta](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta)
and shouldn't be used for production workloads.
During this beta period, the [shared runner pipeline quota](../admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota)
applies for groups and projects in the same manner as Linux runners. This may
change when the beta period ends, as discussed in this [related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/30834).
Windows shared runners on GitLab.com autoscale by launching virtual machines on
the Google Cloud Platform. This solution uses an
[autoscaling driver](https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/autoscaler/tree/master/docs/readme.md)
developed by GitLab for the [custom executor](https://docs.gitlab.com/runner/executors/custom.html).
Windows shared runners execute your CI/CD jobs on `n1-standard-2` instances with
2 vCPUs and 7.5 GB RAM. You can find a full list of available Windows packages in
the [package documentation](https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/gcp/windows-containers/blob/master/cookbooks/preinstalled-software/README.md).
We want to keep iterating to get Windows shared runners in a stable state and
[generally available](https://about.gitlab.com/handbook/product/gitlab-the-product/#generally-available-ga).
You can follow our work towards this goal in the
[related epic](https://gitlab.com/groups/gitlab-org/-/epics/2162).
#### Configuration
The full contents of our `config.toml` are:
NOTE:
Settings that aren't public are shown as `X`.
```toml
concurrent = X
check_interval = 3
[[runners]]
name = "windows-runner"
url = "https://gitlab.com/"
token = "TOKEN"
executor = "custom"
builds_dir = "C:\\GitLab-Runner\\builds"
cache_dir = "C:\\GitLab-Runner\\cache"
shell = "powershell"
[runners.custom]
config_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
config_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "config"]
prepare_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
prepare_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "prepare"]
run_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
run_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "run"]
cleanup_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
cleanup_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "cleanup"]
```
The full contents of our `autoscaler/config.toml` are:
```toml
Provider = "gcp"
Executor = "winrm"
OS = "windows"
LogLevel = "info"
LogFormat = "text"
LogFile = "C:\\GitLab-Runner\\autoscaler\\autoscaler.log"
VMTag = "windows"
[GCP]
ServiceAccountFile = "PATH"
Project = "some-project-df9323"
Zone = "us-east1-c"
MachineType = "n1-standard-2"
Image = "IMAGE"
DiskSize = 50
DiskType = "pd-standard"
Subnetwork = "default"
Network = "default"
Tags = ["TAGS"]
Username = "gitlab_runner"
[WinRM]
MaximumTimeout = 3600
ExecutionMaxRetries = 0
[ProviderCache]
Enabled = true
Directory = "C:\\GitLab-Runner\\autoscaler\\machines"
```
#### Example
Below is a simple `.gitlab-ci.yml` file to show how to start using the
Windows shared runners:
```yaml
.shared_windows_runners:
tags:
- shared-windows
- windows
- windows-1809
stages:
- build
- test
before_script:
- Set-Variable -Name "time" -Value (date -Format "%H:%m")
- echo ${time}
- echo "started by ${GITLAB_USER_NAME}"
build:
extends:
- .shared_windows_runners
stage: build
script:
- echo "running scripts in the build job"
test:
extends:
- .shared_windows_runners
stage: test
script:
- echo "running scripts in the test job"
```
#### Limitations and known issues
- All the limitations mentioned in our [beta
definition](https://about.gitlab.com/handbook/product/#beta).
- The average provisioning time for a new Windows VM is 5 minutes.
This means that you may notice slower build start times
on the Windows shared runner fleet during the beta. In a future
release we intend to update the autoscaler to enable
the pre-provisioning of virtual machines. This is intended to significantly reduce
the time it takes to provision a VM on the Windows fleet. You can
follow along in the [related issue](https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/autoscaler/-/issues/32).
- The Windows shared runner fleet may be unavailable occasionally
for maintenance or updates.
- The Windows shared runner virtual machine instances do not use the
GitLab Docker executor. This means that you can't specify
[`image`](../../ci/yaml/README.md#image) or [`services`](../../ci/yaml/README.md#services) in
your pipeline configuration.
- For the beta release, we have included a set of software packages in
the base VM image. If your CI job requires additional software that's
not included in this list, then you must add installation
commands to [`before_script`](../../ci/yaml/README.md#before_script) or [`script`](../../ci/yaml/README.md#script) to install the required
software. Note that each job runs on a new VM instance, so the
installation of additional software packages needs to be repeated for
each job in your pipeline.
- The job may stay in a pending state for longer than the
Linux shared runners.
- There is the possibility that we introduce breaking changes which will
require updates to pipelines that are using the Windows shared runner
fleet.
For more information, see [choosing a runner](../../ci/runners/README.md).
## Sidekiq

2
doc/user/project/merge_requests/load_performance_testing.md
View File

@ -93,7 +93,7 @@ template that is included with GitLab.
NOTE:
For large scale k6 tests you need to ensure the GitLab Runner instance performing the actual
test is able to handle running the test. Refer to [k6's guidance](https://k6.io/docs/testing-guides/running-large-tests#hardware-considerations)
for spec details. The [default shared GitLab.com runners](../../gitlab_com/#linux-shared-runners)
for spec details. The [default shared GitLab.com runners](../../../ci/runners/README.md#linux-shared-runners)
likely have insufficient specs to handle most large k6 tests.
This template runs the

2
doc/user/project/pages/custom_domains_ssl_tls_certification/dns_concepts.md
View File

@ -5,7 +5,7 @@ group: Release
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# DNS records overview
# DNS records overview **(FREE)**
_Read this document for a brief overview of DNS records in the scope
of GitLab Pages, for beginners in web development._

2
doc/user/project/pages/custom_domains_ssl_tls_certification/index.md
View File

@ -5,7 +5,7 @@ group: Release
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# Custom domains and SSL/TLS Certificates
# Custom domains and SSL/TLS certificates **(FREE)**
Setting up GitLab Pages with custom domains, and adding SSL/TLS certificates to them, are optional features of GitLab Pages.

2
doc/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.md
View File

@ -6,7 +6,7 @@ group: Release
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# GitLab Pages integration with Let's Encrypt
# GitLab Pages integration with Let's Encrypt **(FREE)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/28996) in GitLab 12.1. For versions earlier than GitLab 12.1, see the [manual Let's Encrypt instructions](../lets_encrypt_for_gitlab_pages.md).

2
doc/user/project/pages/custom_domains_ssl_tls_certification/ssl_tls_concepts.md
View File

@ -5,7 +5,7 @@ group: Release
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# SSL/TLS Certificates
# SSL/TLS certificates **(FREE)**
_Read this document for a brief overview of SSL/TLS certificates in
the scope of GitLab Pages, for beginners in web development._

2
doc/user/project/pages/getting_started/pages_ci_cd_template.md
View File

@ -5,7 +5,7 @@ group: Release
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# Create a Pages website by using a CI/CD template
# Create a Pages website by using a CI/CD template **(FREE)**
GitLab provides `.gitlab-ci.yml` templates for the most popular Static Site Generators (SSGs).
You can create your own `.gitlab-ci.yml` file from one of these templates, and run

2
doc/user/project/pages/getting_started/pages_forked_sample_project.md
View File

@ -5,7 +5,7 @@ group: Release
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# Create a Pages website from a forked sample
# Create a Pages website from a forked sample **(FREE)**
GitLab provides [sample projects for the most popular Static Site Generators (SSG)](https://gitlab.com/pages).
You can fork one of the sample projects and run the CI/CD pipeline to generate a Pages website.

2
doc/user/project/pages/getting_started/pages_from_scratch.md
View File

@ -4,7 +4,7 @@ group: Release
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# Create a GitLab Pages website from scratch
# Create a GitLab Pages website from scratch **(FREE)**
This tutorial shows you how to create a Pages site from scratch. You start with
a blank project and create your own CI file, which gives instruction to

2
doc/user/project/pages/getting_started/pages_new_project_template.md
View File

@ -5,7 +5,7 @@ group: Release
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# Create a Pages website from a template
# Create a Pages website from a template **(FREE)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/47857) in GitLab 11.8.

2
doc/user/project/pages/getting_started_part_one.md
View File

@ -4,7 +4,7 @@ group: Release
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# GitLab Pages domain names, URLs, and base URLs
# GitLab Pages domain names, URLs, and base URLs **(FREE)**
On this document, learn how to name your project for GitLab Pages
according to your intended website's URL.

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

@ -5,7 +5,7 @@ group: Release
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# GitLab Pages
# GitLab Pages **(FREE)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80) in GitLab Enterprise Edition 8.3.
> - Custom CNAMEs with TLS support were [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/173) in GitLab Enterprise Edition 8.5.

4
doc/user/project/pages/introduction.md
View File

@ -4,7 +4,7 @@ group: Release
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# Exploring GitLab Pages
# Exploring GitLab Pages **(FREE)**
This document is a user guide to explore the options and settings
GitLab Pages offers.
@ -324,4 +324,4 @@ pages:
- public
```
The `FF_USE_FASTZIP` variable enables the [feature flag](https://docs.gitlab.com/runner/configuration/feature-flags.html#available-feature-flags) which is needed for [`ARTIFACT_COMPRESSION_LEVEL`](../../../ci/runners/README.md#artifact-and-cache-settings).
The `FF_USE_FASTZIP` variable enables the [feature flag](https://docs.gitlab.com/runner/configuration/feature-flags.html#available-feature-flags) which is needed for [`ARTIFACT_COMPRESSION_LEVEL`](../../../ci/runners/configure_runners.md#artifact-and-cache-settings).

2
doc/user/project/pages/lets_encrypt_for_gitlab_pages.md
View File

@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
description: "How to secure GitLab Pages websites with Let's Encrypt (manual process, deprecated)."
---
# Let's Encrypt for GitLab Pages (manual process, deprecated)
# Let's Encrypt for GitLab Pages (manual process, deprecated) **(FREE)**
WARNING:
This method is still valid but was **deprecated** in favor of the

2
doc/user/project/pages/pages_access_control.md
View File

@ -5,7 +5,7 @@ group: Release
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# GitLab Pages Access Control
# GitLab Pages access control **(FREE)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/33422) in GitLab 11.5.
> - Available on GitLab.com in GitLab 12.4.

2
doc/user/project/pages/redirects.md
View File

@ -4,7 +4,7 @@ group: Release
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# Create redirects for GitLab Pages
# Create redirects for GitLab Pages **(FREE)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/24) in GitLab Pages 1.25.0 and GitLab 13.4 behind a feature flag, disabled by default.
> - [Became enabled by default](https://gitlab.com/gitlab-org/gitlab-pages/-/merge_requests/367) in GitLab 13.5.

4
lib/gitlab/database/background_migration/batched_migration.rb
View File

@ -14,6 +14,10 @@ module Gitlab
class_name: 'Gitlab::Database::BackgroundMigration::BatchedJob',
foreign_key: :batched_background_migration_id
validates :job_arguments, uniqueness: {
scope: [:job_class_name, :table_name, :column_name]
}
scope :queue_order, -> { order(id: :asc) }
scope :queued, -> { where(status: [:active, :paused]) }
scope :for_configuration, ->(job_class_name, table_name, column_name, job_arguments) do

7
lib/gitlab/database/load_balancing.rb
View File

@ -97,16 +97,9 @@ module Gitlab
# posting the write location of the database if load balancing is
# configured.
def self.configured?
return false unless feature_available?
hosts.any? || service_discovery_enabled?
end
# Temporarily disabled for FOSS until move from EE to FOSS is complete
def self.feature_available?
Gitlab.ee? || Gitlab::Utils.to_boolean(ENV['ENABLE_LOAD_BALANCING_FOR_FOSS'], default: false)
end
def self.start_service_discovery
return unless service_discovery_enabled?

36
lib/gitlab/database/migrations/background_migration_helpers.rb
View File

@ -131,6 +131,42 @@ module Gitlab
final_delay
end
# Requeue pending jobs previously queued with #queue_background_migration_jobs_by_range_at_intervals
#
# This method is useful to schedule jobs that had previously failed.
#
# job_class_name - The background migration job class as a string
# delay_interval - The duration between each job's scheduled time
# batch_size - The maximum number of jobs to fetch to memory from the database.
def requeue_background_migration_jobs_by_range_at_intervals(job_class_name, delay_interval, batch_size: BATCH_SIZE, initial_delay: 0)
# To not overload the worker too much we enforce a minimum interval both
# when scheduling and performing jobs.
delay_interval = [delay_interval, BackgroundMigrationWorker.minimum_interval].max
final_delay = 0
job_counter = 0
jobs = Gitlab::Database::BackgroundMigrationJob.pending.where(class_name: job_class_name)
jobs.each_batch(of: batch_size) do |job_batch|
job_batch.each do |job|
final_delay = initial_delay + delay_interval * job_counter
migrate_in(final_delay, job_class_name, job.arguments)
job_counter += 1
end
end
duration = initial_delay + delay_interval * job_counter
say <<~SAY
Scheduled #{job_counter} #{job_class_name} jobs with an interval of #{delay_interval} seconds.
The migration is expected to take at least #{duration} seconds. Expect all jobs to have completed after #{Time.zone.now + duration}."
SAY
duration
end
# Creates a batched background migration for the given table. A batched migration runs one job
# at a time, computing the bounds of the next batch based on the current migration settings and the previous
# batch bounds. Each job's execution status is tracked in the database as the migration runs. The given job

1
lib/gitlab/import_export/group/import_export.yml
View File

@ -77,6 +77,7 @@ ee:
- :award_emoji
- events:
- :push_event_payload
- :system_note_metadata
- boards:
- :board_assignee
- :milestone

12
locale/gitlab.pot
View File

@ -5812,6 +5812,9 @@ msgstr ""
msgid "CVE|Why Request a CVE ID?"
msgstr ""
msgid "Cadence is not automated"
msgstr ""
msgid "Callback URL"
msgstr ""
@ -10042,6 +10045,9 @@ msgstr ""
msgid "DastConfig|DAST Settings"
msgstr ""
msgid "DastConfig|Generate code snippet"
msgstr ""
msgid "DastConfig|Scan Configuration"
msgstr ""
@ -33123,6 +33129,9 @@ msgstr ""
msgid "This chart could not be displayed"
msgstr ""
msgid "This code snippet contains everything reflected in the configuration form. Copy and paste it into %{linkStart}.gitlab-ci.yml%{linkEnd} file and save your changes. Future %{scanType} scans will use these settings."
msgstr ""
msgid "This comment changed after you started editing it. Review the %{startTag}updated comment%{endTag} to ensure information is not lost."
msgstr ""
@ -37934,6 +37943,9 @@ msgstr ""
msgid "already being used for another group or project %{timebox_name}."
msgstr ""
msgid "already being used for another iteration within this cadence."
msgstr ""
msgid "already has a \"created\" issue link"
msgstr ""

1
spec/factories/gitlab/database/background_migration/batched_migrations.rb
View File

@ -9,6 +9,7 @@ FactoryBot.define do
job_class_name { 'CopyColumnUsingBackgroundMigrationJob' }
table_name { :events }
column_name { :id }
sequence(:job_arguments) { |n| [["column_#{n}"], ["column_#{n}_convert_to_bigint"]] }
total_tuple_count { 10_000 }
pause_ms { 100 }
end

BIN
spec/fixtures/bulk_imports/epics.ndjson.gz vendored
View File

Binary file not shown.

81
spec/frontend/releases/components/app_index_apollo_client_spec.js
View File

@ -4,13 +4,14 @@ import VueApollo from 'vue-apollo';
import createMockApollo from 'helpers/mock_apollo_helper';
import { shallowMountExtended } from 'helpers/vue_test_utils_helper';
import createFlash from '~/flash';
import { historyPushState } from '~/lib/utils/common_utils';
import ReleasesIndexApolloClientApp from '~/releases/components/app_index_apollo_client.vue';
import ReleaseBlock from '~/releases/components/release_block.vue';
import ReleaseSkeletonLoader from '~/releases/components/release_skeleton_loader.vue';
import ReleasesEmptyState from '~/releases/components/releases_empty_state.vue';
import ReleasesPaginationApolloClient from '~/releases/components/releases_pagination_apollo_client.vue';
import ReleasesSortApolloClient from '~/releases/components/releases_sort_apollo_client.vue';
import { PAGE_SIZE, RELEASED_AT_DESC, CREATED_ASC } from '~/releases/constants';
import { PAGE_SIZE, CREATED_ASC, DEFAULT_SORT } from '~/releases/constants';
import allReleasesQuery from '~/releases/graphql/queries/all_releases.query.graphql';
Vue.use(VueApollo);
@ -23,6 +24,7 @@ jest.mock('~/lib/utils/common_utils', () => ({
getParameterByName: jest
.fn()
.mockImplementation((parameterName) => mockQueryParams[parameterName]),
historyPushState: jest.fn(),
}));
describe('app_index_apollo_client.vue', () => {
@ -225,7 +227,7 @@ describe('app_index_apollo_client.vue', () => {
expect(allReleasesQueryMock).toHaveBeenCalledWith({
first: PAGE_SIZE,
fullPath: projectPath,
sort: RELEASED_AT_DESC,
sort: DEFAULT_SORT,
});
});
});
@ -241,7 +243,7 @@ describe('app_index_apollo_client.vue', () => {
before,
last: PAGE_SIZE,
fullPath: projectPath,
sort: RELEASED_AT_DESC,
sort: DEFAULT_SORT,
});
});
});
@ -257,7 +259,7 @@ describe('app_index_apollo_client.vue', () => {
after,
first: PAGE_SIZE,
fullPath: projectPath,
sort: RELEASED_AT_DESC,
sort: DEFAULT_SORT,
});
});
});
@ -273,7 +275,7 @@ describe('app_index_apollo_client.vue', () => {
after,
first: PAGE_SIZE,
fullPath: projectPath,
sort: RELEASED_AT_DESC,
sort: DEFAULT_SORT,
});
});
});
@ -320,21 +322,82 @@ describe('app_index_apollo_client.vue', () => {
createComponent();
});
it(`sorts by ${RELEASED_AT_DESC} by default`, () => {
it(`sorts by ${DEFAULT_SORT} by default`, () => {
expect(allReleasesQueryMock.mock.calls).toEqual([
[expect.objectContaining({ sort: RELEASED_AT_DESC })],
[expect.objectContaining({ sort: DEFAULT_SORT })],
]);
});
it('requeries the GraphQL endpoint when the sort is changed', async () => {
it('requeries the GraphQL endpoint and updates the URL when the sort is changed', async () => {
findSort().vm.$emit('input', CREATED_ASC);
await wrapper.vm.$nextTick();
expect(allReleasesQueryMock.mock.calls).toEqual([
[expect.objectContaining({ sort: RELEASED_AT_DESC })],
[expect.objectContaining({ sort: DEFAULT_SORT })],
[expect.objectContaining({ sort: CREATED_ASC })],
]);
// URL manipulation is tested in more detail in the `describe` block below
expect(historyPushState).toHaveBeenCalled();
});
it('does not requery the GraphQL endpoint or update the URL if the sort is updated to the same value', async () => {
findSort().vm.$emit('input', DEFAULT_SORT);
await wrapper.vm.$nextTick();
expect(allReleasesQueryMock.mock.calls).toEqual([
[expect.objectContaining({ sort: DEFAULT_SORT })],
]);
expect(historyPushState).not.toHaveBeenCalled();
});
});
describe('sorting + pagination interaction', () => {
const nonPaginationQueryParam = 'nonPaginationQueryParam';
beforeEach(() => {
historyPushState.mockImplementation((newUrl) => {
mockQueryParams = Object.fromEntries(new URL(newUrl).searchParams);
});
});
describe.each`
queryParamsBefore | paramName | paramInitialValue
${{ before, nonPaginationQueryParam }} | ${'before'} | ${before}
${{ after, nonPaginationQueryParam }} | ${'after'} | ${after}
`(
'when the URL contains a "$paramName" pagination cursor',
({ queryParamsBefore, paramName, paramInitialValue }) => {
beforeEach(async () => {
mockQueryParams = queryParamsBefore;
createComponent();
findSort().vm.$emit('input', CREATED_ASC);
await wrapper.vm.$nextTick();
});
it(`resets the page's "${paramName}" pagination cursor when the sort is changed`, () => {
const firstRequestVariables = allReleasesQueryMock.mock.calls[0][0];
const secondRequestVariables = allReleasesQueryMock.mock.calls[1][0];
expect(firstRequestVariables[paramName]).toBe(paramInitialValue);
expect(secondRequestVariables[paramName]).toBeUndefined();
});
it(`updates the URL to not include the "${paramName}" URL query parameter`, () => {
expect(historyPushState).toHaveBeenCalledTimes(1);
const updatedUrlQueryParams = Object.fromEntries(
new URL(historyPushState.mock.calls[0][0]).searchParams,
);
expect(updatedUrlQueryParams[paramName]).toBeUndefined();
});
},
);
});
});

97
spec/frontend/search/topbar/components/searchable_dropdown_item_spec.js Normal file
View File

@ -0,0 +1,97 @@
import { GlDropdownItem, GlAvatar } from '@gitlab/ui';
import { shallowMountExtended } from 'helpers/vue_test_utils_helper';
import { MOCK_GROUPS } from 'jest/search/mock_data';
import { truncateNamespace } from '~/lib/utils/text_utility';
import SearchableDropdownItem from '~/search/topbar/components/searchable_dropdown_item.vue';
import { GROUP_DATA } from '~/search/topbar/constants';
describe('Global Search Searchable Dropdown Item', () => {
let wrapper;
const defaultProps = {
item: MOCK_GROUPS[0],
selectedItem: MOCK_GROUPS[0],
name: GROUP_DATA.name,
fullName: GROUP_DATA.fullName,
};
const createComponent = (props) => {
wrapper = shallowMountExtended(SearchableDropdownItem, {
propsData: {
...defaultProps,
...props,
},
});
};
afterEach(() => {
wrapper.destroy();
});
const findGlDropdownItem = () => wrapper.findComponent(GlDropdownItem);
const findGlAvatar = () => wrapper.findComponent(GlAvatar);
const findDropdownTitle = () => wrapper.findByTestId('item-title');
const findDropdownSubtitle = () => wrapper.findByTestId('item-namespace');
describe('template', () => {
describe('always', () => {
beforeEach(() => {
createComponent();
});
it('renders GlDropdownItem', () => {
expect(findGlDropdownItem().exists()).toBe(true);
});
it('renders GlAvatar', () => {
expect(findGlAvatar().exists()).toBe(true);
});
it('renders Dropdown Title correctly', () => {
const titleEl = findDropdownTitle();
expect(titleEl.exists()).toBe(true);
expect(titleEl.text()).toBe(MOCK_GROUPS[0][GROUP_DATA.name]);
});
it('renders Dropdown Subtitle correctly', () => {
const subtitleEl = findDropdownSubtitle();
expect(subtitleEl.exists()).toBe(true);
expect(subtitleEl.text()).toBe(truncateNamespace(MOCK_GROUPS[0][GROUP_DATA.fullName]));
});
});
describe('when item === selectedItem', () => {
beforeEach(() => {
createComponent({ item: MOCK_GROUPS[0], selectedItem: MOCK_GROUPS[0] });
});
it('marks the dropdown as checked', () => {
expect(findGlDropdownItem().attributes('ischecked')).toBe('true');
});
});
describe('when item !== selectedItem', () => {
beforeEach(() => {
createComponent({ item: MOCK_GROUPS[0], selectedItem: MOCK_GROUPS[1] });
});
it('marks the dropdown as not checked', () => {
expect(findGlDropdownItem().attributes('ischecked')).toBeUndefined();
});
});
});
describe('actions', () => {
beforeEach(() => {
createComponent();
});
it('clicking the dropdown item $emits change with the item', () => {
findGlDropdownItem().vm.$emit('click');
expect(wrapper.emitted('change')[0]).toEqual([MOCK_GROUPS[0]]);
});
});
});

82
spec/frontend/search/topbar/components/searchable_dropdown_spec.js
View File

@ -1,17 +1,10 @@
import {
GlDropdown,
GlDropdownItem,
GlSearchBoxByType,
GlSkeletonLoader,
GlAvatar,
} from '@gitlab/ui';
import { GlDropdown, GlDropdownItem, GlSearchBoxByType, GlSkeletonLoader } from '@gitlab/ui';
import { shallowMount, mount } from '@vue/test-utils';
import Vue from 'vue';
import Vuex from 'vuex';
import { extendedWrapper } from 'helpers/vue_test_utils_helper';
import { MOCK_GROUPS, MOCK_GROUP, MOCK_QUERY } from 'jest/search/mock_data';
import { truncateNamespace } from '~/lib/utils/text_utility';
import SearchableDropdown from '~/search/topbar/components/searchable_dropdown.vue';
import SearchableDropdownItem from '~/search/topbar/components/searchable_dropdown_item.vue';
import { ANY_OPTION, GROUP_DATA } from '~/search/topbar/constants';
Vue.use(Vuex);
@ -36,37 +29,27 @@ describe('Global Search Searchable Dropdown', () => {
},
});
wrapper = extendedWrapper(
mountFn(SearchableDropdown, {
store,
propsData: {
...defaultProps,
...props,
},
}),
);
wrapper = mountFn(SearchableDropdown, {
store,
propsData: {
...defaultProps,
...props,
},
});
};
afterEach(() => {
wrapper.destroy();
wrapper = null;
});
const findGlDropdown = () => wrapper.find(GlDropdown);
const findGlDropdownSearch = () => findGlDropdown().find(GlSearchBoxByType);
const findGlDropdown = () => wrapper.findComponent(GlDropdown);
const findGlDropdownSearch = () => findGlDropdown().findComponent(GlSearchBoxByType);
const findDropdownText = () => findGlDropdown().find('.dropdown-toggle-text');
const findDropdownItems = () => findGlDropdown().findAll(GlDropdownItem);
const findDropdownItemTitles = () => wrapper.findAllByTestId('item-title');
const findDropdownItemNamespaces = () => wrapper.findAllByTestId('item-namespace');
const findDropdownAvatars = () => wrapper.findAllComponents(GlAvatar);
const findAnyDropdownItem = () => findDropdownItems().at(0);
const findFirstGroupDropdownItem = () => findDropdownItems().at(1);
const findLoader = () => wrapper.find(GlSkeletonLoader);
const findDropdownItemTitlesText = () => findDropdownItemTitles().wrappers.map((w) => w.text());
const findDropdownItemNamespacesText = () =>
findDropdownItemNamespaces().wrappers.map((w) => w.text());
const findDropdownAvatarUrls = () => findDropdownAvatars().wrappers.map((w) => w.props('src'));
const findSearchableDropdownItems = () =>
findGlDropdown().findAllComponents(SearchableDropdownItem);
const findAnyDropdownItem = () => findGlDropdown().findComponent(GlDropdownItem);
const findFirstGroupDropdownItem = () => findSearchableDropdownItems().at(0);
const findLoader = () => wrapper.findComponent(GlSkeletonLoader);
describe('template', () => {
beforeEach(() => {
@ -109,19 +92,12 @@ describe('Global Search Searchable Dropdown', () => {
expect(findLoader().exists()).toBe(false);
});
it('renders titles correctly including Any', () => {
const resultsIncludeAny = ['Any'].concat(MOCK_GROUPS.map((n) => n[GROUP_DATA.name]));
expect(findDropdownItemTitlesText()).toStrictEqual(resultsIncludeAny);
it('renders the Any Dropdown', () => {
expect(findAnyDropdownItem().exists()).toBe(true);
});
it('renders namespaces truncated correctly', () => {
const namespaces = MOCK_GROUPS.map((n) => truncateNamespace(n[GROUP_DATA.fullName]));
expect(findDropdownItemNamespacesText()).toStrictEqual(namespaces);
});
it('renders GlAvatar for each item', () => {
const avatars = MOCK_GROUPS.map((n) => n.avatar_url);
expect(findDropdownAvatarUrls()).toStrictEqual(avatars);
it('renders SearchableDropdownItem for each item', () => {
expect(findSearchableDropdownItems()).toHaveLength(MOCK_GROUPS.length);
});
});
@ -134,18 +110,12 @@ describe('Global Search Searchable Dropdown', () => {
expect(findLoader().exists()).toBe(true);
});
it('renders only Any in dropdown', () => {
expect(findDropdownItemTitlesText()).toStrictEqual(['Any']);
});
});
describe('when item is selected', () => {
beforeEach(() => {
createComponent({}, { items: MOCK_GROUPS, selectedItem: MOCK_GROUPS[0] });
it('renders the Any Dropdown', () => {
expect(findAnyDropdownItem().exists()).toBe(true);
});
it('marks the dropdown as checked', () => {
expect(findFirstGroupDropdownItem().attributes('ischecked')).toBe('true');
it('does not render SearchableDropdownItem', () => {
expect(findSearchableDropdownItems()).toHaveLength(0);
});
});
});
@ -184,8 +154,8 @@ describe('Global Search Searchable Dropdown', () => {
expect(wrapper.emitted('change')[0]).toEqual([ANY_OPTION]);
});
it('clicking result dropdown item $emits @change with result', () => {
findFirstGroupDropdownItem().vm.$emit('click');
it('on SearchableDropdownItem @change, the wrapper $emits change with the item', () => {
findFirstGroupDropdownItem().vm.$emit('change', MOCK_GROUPS[0]);
expect(wrapper.emitted('change')[0]).toEqual([MOCK_GROUPS[0]]);
});

7
spec/graphql/mutations/todos/mark_all_done_spec.rb
View File

@ -21,26 +21,25 @@ RSpec.describe Mutations::Todos::MarkAllDone do
describe '#resolve' do
it 'marks all pending todos as done' do
updated_todo_ids, todos = mutation_for(current_user).resolve.values_at(:updated_ids, :todos)
todos = mutation_for(current_user).resolve[:todos]
expect(todo1.reload.state).to eq('done')
expect(todo2.reload.state).to eq('done')
expect(todo3.reload.state).to eq('done')
expect(other_user_todo.reload.state).to eq('pending')
expect(updated_todo_ids).to contain_exactly(todo1.id, todo3.id)
expect(todos).to contain_exactly(todo1, todo3)
end
it 'behaves as expected if there are no todos for the requesting user' do
updated_todo_ids = mutation_for(user3).resolve.dig(:updated_ids)
todos = mutation_for(user3).resolve[:todos]
expect(todo1.reload.state).to eq('pending')
expect(todo2.reload.state).to eq('done')
expect(todo3.reload.state).to eq('pending')
expect(other_user_todo.reload.state).to eq('pending')
expect(updated_todo_ids).to be_empty
expect(todos).to be_empty
end
context 'when user is not logged in' do

22
spec/graphql/resolvers/group_packages_resolver_spec.rb
View File

@ -7,7 +7,7 @@ RSpec.describe Resolvers::GroupPackagesResolver do
let_it_be(:user) { create(:user) }
let_it_be(:group) { create(:group, :public) }
let_it_be(:project) { create(:project, :public, group: group) }
let_it_be(:project) { create(:project, :public, group: group, path: 'a') }
let(:args) do
{ sort: :created_desc }
@ -17,5 +17,25 @@ RSpec.describe Resolvers::GroupPackagesResolver do
subject { resolve(described_class, ctx: { current_user: user }, obj: group, args: args).to_a }
it_behaves_like 'group and projects packages resolver'
describe 'project_path sorting' do
let_it_be(:project2) { create(:project, :public, group: group, path: 'b') }
let_it_be(:package) { create(:package, project: project ) }
let_it_be(:package2) { create(:package, project: project2 ) }
let_it_be(:package3) { create(:package, project: project ) }
let_it_be(:package4) { create(:package, project: project2 ) }
context 'filter by package_name' do
let(:args) { { sort: :project_path_desc } }
it { is_expected.to eq([package4, package2, package3, package]) }
end
context 'filter by package_type' do
let(:args) { { sort: :project_path_asc } }
it { is_expected.to eq([package, package3, package2, package4]) }
end
end
end
end

22
spec/graphql/types/mutation_type_spec.rb
View File

@ -15,28 +15,6 @@ RSpec.describe Types::MutationType do
expect(described_class).to have_graphql_mutation(Mutations::MergeRequests::SetDraft)
end
describe 'deprecated and aliased mutations' do
using RSpec::Parameterized::TableSyntax
where(:alias_name, :canonical_name) do
'AddAwardEmoji' | 'AwardEmojiAdd'
'RemoveAwardEmoji' | 'AwardEmojiRemove'
'ToggleAwardEmoji' | 'AwardEmojiToggle'
end
with_them do
let(:alias_field) { get_field(alias_name) }
let(:canonical_field) { get_field(canonical_name) }
it { expect(alias_field).to be_present }
it { expect(canonical_field).to be_present }
it { expect(alias_field.deprecation_reason).to be_present }
it { expect(canonical_field.deprecation_reason).not_to be_present }
it { expect(alias_field.resolver.fields).to eq(canonical_field.resolver.fields) }
it { expect(alias_field.resolver.arguments).to eq(canonical_field.resolver.arguments) }
end
end
def get_field(name)
described_class.fields[GraphqlHelpers.fieldnamerize(name)]
end

9
spec/graphql/types/packages/package_group_sort_enum_spec.rb Normal file
View File

@ -0,0 +1,9 @@
# frozen_string_literal: true
require 'spec_helper'
RSpec.describe GitlabSchema.types['PackageGroupSort'] do
it 'exposes all package group sort values' do
expect(described_class.values.keys).to contain_exactly(*%w[CREATED_DESC CREATED_ASC NAME_DESC NAME_ASC PROJECT_PATH_DESC PROJECT_PATH_ASC VERSION_DESC VERSION_ASC TYPE_DESC TYPE_ASC])
end
end

9
spec/graphql/types/packages/package_sort_enum_spec.rb Normal file
View File

@ -0,0 +1,9 @@
# frozen_string_literal: true
require 'spec_helper'
RSpec.describe GitlabSchema.types['PackageSort'] do
it 'exposes all package sort values' do
expect(described_class.values.keys).to contain_exactly(*%w[CREATED_DESC CREATED_ASC NAME_DESC NAME_ASC VERSION_DESC VERSION_ASC TYPE_DESC TYPE_ASC])
end
end

28
spec/graphql/types/snippet_type_spec.rb
View File

@ -13,7 +13,7 @@ RSpec.describe GitlabSchema.types['Snippet'] do
:visibility_level, :created_at, :updated_at,
:web_url, :raw_url, :ssh_url_to_repo, :http_url_to_repo,
:notes, :discussions, :user_permissions,
:description_html, :blob, :blobs]
:description_html, :blobs]
expect(described_class).to have_graphql_fields(*expected_fields)
end
@ -133,32 +133,6 @@ RSpec.describe GitlabSchema.types['Snippet'] do
end
end
describe '#blob' do
let(:query_blob) { subject.dig('data', 'snippets', 'nodes')[0]['blob'] }
subject { GitlabSchema.execute(snippet_query_for(field: 'blob'), context: { current_user: user }).as_json }
context 'when snippet has repository' do
let!(:snippet) { create(:personal_snippet, :repository, :public, author: user) }
let(:blob) { snippet.blobs.first }
it 'returns the first blob from the repository' do
expect(query_blob['name']).to eq blob.name
expect(query_blob['path']).to eq blob.path
end
end
context 'when snippet does not have a repository' do
let!(:snippet) { create(:personal_snippet, :public, author: user) }
let(:blob) { snippet.blob }
it 'returns SnippetBlob type' do
expect(query_blob['name']).to eq blob.name
expect(query_blob['path']).to eq blob.path
end
end
end
describe '#blobs' do
let_it_be(:snippet) { create(:personal_snippet, :public, author: user) }

22
spec/graphql/types/snippets/blob_viewer_type_spec.rb
View File

@ -31,7 +31,7 @@ RSpec.describe GitlabSchema.types['SnippetBlobViewer'] do
end
it 'returns false' do
snippet_blob = subject.dig('data', 'snippets', 'edges')[0].dig('node', 'blob')
snippet_blob = subject.dig('data', 'snippets', 'edges').first.dig('node', 'blobs', 'nodes').find { |b| b['path'] == blob.path }
expect(snippet_blob['path']).to eq blob.path
expect(blob_attribute).to be_nil
@ -47,10 +47,12 @@ RSpec.describe GitlabSchema.types['SnippetBlobViewer'] do
snippets(ids: "#{snippet.to_global_id}") {
edges {
node {
blob {
path
simpleViewer {
collapsed
blobs {
nodes {
path
simpleViewer {
collapsed
}
}
}
}
@ -73,10 +75,12 @@ RSpec.describe GitlabSchema.types['SnippetBlobViewer'] do
snippets(ids: "#{snippet.to_global_id}") {
edges {
node {
blob {
path
simpleViewer {
tooLarge
blobs {
nodes {
path
simpleViewer {
tooLarge
}
}
}
}

6
spec/lib/gitlab/database/background_migration/batched_migration_spec.rb
View File

@ -19,6 +19,12 @@ RSpec.describe Gitlab::Database::BackgroundMigration::BatchedMigration, type: :m
end
end
describe 'validations' do
subject { build(:batched_background_migration) }
it { is_expected.to validate_uniqueness_of(:job_arguments).scoped_to(:job_class_name, :table_name, :column_name) }
end
describe '.queue_order' do
let!(:migration1) { create(:batched_background_migration) }
let!(:migration2) { create(:batched_background_migration) }

25
spec/lib/gitlab/database/load_balancing_spec.rb
View File

@ -182,31 +182,6 @@ RSpec.describe Gitlab::Database::LoadBalancing do
expect(described_class.enable?).to eq(true)
end
end
context 'FOSS' do
before do
allow(Gitlab).to receive(:ee?).and_return(false)
stub_env('ENABLE_LOAD_BALANCING_FOR_FOSS', 'false')
end
it 'is disabled' do
expect(described_class.enable?).to eq(false)
end
end
context 'EE' do
before do
allow(Gitlab).to receive(:ee?).and_return(true)
end
it 'is enabled' do
allow(described_class).to receive(:hosts).and_return(%w(foo))
allow(Gitlab::Runtime).to receive(:sidekiq?).and_return(false)
expect(described_class.enable?).to eq(true)
end
end
end
describe '.configured?' do

92
spec/lib/gitlab/database/migrations/background_migration_helpers_spec.rb
View File

@ -242,6 +242,98 @@ RSpec.describe Gitlab::Database::Migrations::BackgroundMigrationHelpers do
end
end
describe '#requeue_background_migration_jobs_by_range_at_intervals' do
let!(:job_class_name) { 'TestJob' }
let!(:pending_job_1) { create(:background_migration_job, class_name: job_class_name, status: :pending, arguments: [1, 2]) }
let!(:pending_job_2) { create(:background_migration_job, class_name: job_class_name, status: :pending, arguments: [3, 4]) }
let!(:successful_job_1) { create(:background_migration_job, class_name: job_class_name, status: :succeeded, arguments: [5, 6]) }
let!(:successful_job_2) { create(:background_migration_job, class_name: job_class_name, status: :succeeded, arguments: [7, 8]) }
around do |example|
freeze_time do
Sidekiq::Testing.fake! do
example.run
end
end
end
subject { model.requeue_background_migration_jobs_by_range_at_intervals(job_class_name, 10.minutes) }
it 'returns the expected duration' do
expect(subject).to eq(20.minutes)
end
context 'when nothing is queued' do
subject { model.requeue_background_migration_jobs_by_range_at_intervals('FakeJob', 10.minutes) }
it 'returns expected duration of zero when nothing gets queued' do
expect(subject).to eq(0)
end
end
it 'queues pending jobs' do
subject
expect(BackgroundMigrationWorker.jobs[0]['args']).to eq([job_class_name, [1, 2]])
expect(BackgroundMigrationWorker.jobs[0]['at']).to be_nil
expect(BackgroundMigrationWorker.jobs[1]['args']).to eq([job_class_name, [3, 4]])
expect(BackgroundMigrationWorker.jobs[1]['at']).to eq(10.minutes.from_now.to_f)
end
context 'with batch_size option' do
subject { model.requeue_background_migration_jobs_by_range_at_intervals(job_class_name, 10.minutes, batch_size: 1) }
it 'returns the expected duration' do
expect(subject).to eq(20.minutes)
end
it 'queues pending jobs' do
subject
expect(BackgroundMigrationWorker.jobs[0]['args']).to eq([job_class_name, [1, 2]])
expect(BackgroundMigrationWorker.jobs[0]['at']).to be_nil
expect(BackgroundMigrationWorker.jobs[1]['args']).to eq([job_class_name, [3, 4]])
expect(BackgroundMigrationWorker.jobs[1]['at']).to eq(10.minutes.from_now.to_f)
end
it 'retrieve jobs in batches' do
jobs = double('jobs')
expect(Gitlab::Database::BackgroundMigrationJob).to receive(:pending) { jobs }
allow(jobs).to receive(:where).with(class_name: job_class_name) { jobs }
expect(jobs).to receive(:each_batch).with(of: 1)
subject
end
end
context 'with initial_delay option' do
let_it_be(:initial_delay) { 3.minutes }
subject { model.requeue_background_migration_jobs_by_range_at_intervals(job_class_name, 10.minutes, initial_delay: initial_delay) }
it 'returns the expected duration' do
expect(subject).to eq(23.minutes)
end
it 'queues pending jobs' do
subject
expect(BackgroundMigrationWorker.jobs[0]['args']).to eq([job_class_name, [1, 2]])
expect(BackgroundMigrationWorker.jobs[0]['at']).to eq(3.minutes.from_now.to_f)
expect(BackgroundMigrationWorker.jobs[1]['args']).to eq([job_class_name, [3, 4]])
expect(BackgroundMigrationWorker.jobs[1]['at']).to eq(13.minutes.from_now.to_f)
end
context 'when nothing is queued' do
subject { model.requeue_background_migration_jobs_by_range_at_intervals('FakeJob', 10.minutes) }
it 'returns expected duration of zero when nothing gets queued' do
expect(subject).to eq(0)
end
end
end
end
describe '#perform_background_migration_inline?' do
it 'returns true in a test environment' do
stub_rails_env('test')

93
spec/migrations/retry_backfill_traversal_ids_spec.rb Normal file
View File

@ -0,0 +1,93 @@
# frozen_string_literal: true
require 'spec_helper'
require Rails.root.join('db', 'post_migrate', '20210604070207_retry_backfill_traversal_ids.rb')
RSpec.describe RetryBackfillTraversalIds, :migration do
include ReloadHelpers
let_it_be(:namespaces_table) { table(:namespaces) }
context 'when BackfillNamespaceTraversalIdsRoots jobs are pending' do
before do
table(:background_migration_jobs).create!(
class_name: 'BackfillNamespaceTraversalIdsRoots',
arguments: [1, 4, 100],
status: Gitlab::Database::BackgroundMigrationJob.statuses['pending']
)
table(:background_migration_jobs).create!(
class_name: 'BackfillNamespaceTraversalIdsRoots',
arguments: [5, 9, 100],
status: Gitlab::Database::BackgroundMigrationJob.statuses['succeeded']
)
end
it 'queues pending jobs' do
migrate!
expect(BackgroundMigrationWorker.jobs.length).to eq(1)
expect(BackgroundMigrationWorker.jobs[0]['args']).to eq(['BackfillNamespaceTraversalIdsRoots', [1, 4, 100]])
expect(BackgroundMigrationWorker.jobs[0]['at']).to be_nil
end
end
context 'when BackfillNamespaceTraversalIdsChildren jobs are pending' do
before do
table(:background_migration_jobs).create!(
class_name: 'BackfillNamespaceTraversalIdsChildren',
arguments: [1, 4, 100],
status: Gitlab::Database::BackgroundMigrationJob.statuses['pending']
)
table(:background_migration_jobs).create!(
class_name: 'BackfillNamespaceTraversalIdsRoots',
arguments: [5, 9, 100],
status: Gitlab::Database::BackgroundMigrationJob.statuses['succeeded']
)
end
it 'queues pending jobs' do
migrate!
expect(BackgroundMigrationWorker.jobs.length).to eq(1)
expect(BackgroundMigrationWorker.jobs[0]['args']).to eq(['BackfillNamespaceTraversalIdsChildren', [1, 4, 100]])
expect(BackgroundMigrationWorker.jobs[0]['at']).to be_nil
end
end
context 'when BackfillNamespaceTraversalIdsRoots and BackfillNamespaceTraversalIdsChildren jobs are pending' do
before do
table(:background_migration_jobs).create!(
class_name: 'BackfillNamespaceTraversalIdsRoots',
arguments: [1, 4, 100],
status: Gitlab::Database::BackgroundMigrationJob.statuses['pending']
)
table(:background_migration_jobs).create!(
class_name: 'BackfillNamespaceTraversalIdsChildren',
arguments: [5, 9, 100],
status: Gitlab::Database::BackgroundMigrationJob.statuses['pending']
)
table(:background_migration_jobs).create!(
class_name: 'BackfillNamespaceTraversalIdsRoots',
arguments: [11, 14, 100],
status: Gitlab::Database::BackgroundMigrationJob.statuses['succeeded']
)
table(:background_migration_jobs).create!(
class_name: 'BackfillNamespaceTraversalIdsChildren',
arguments: [15, 19, 100],
status: Gitlab::Database::BackgroundMigrationJob.statuses['succeeded']
)
end
it 'queues pending jobs' do
freeze_time do
migrate!
expect(BackgroundMigrationWorker.jobs.length).to eq(2)
expect(BackgroundMigrationWorker.jobs[0]['args']).to eq(['BackfillNamespaceTraversalIdsRoots', [1, 4, 100]])
expect(BackgroundMigrationWorker.jobs[0]['at']).to be_nil
expect(BackgroundMigrationWorker.jobs[1]['args']).to eq(['BackfillNamespaceTraversalIdsChildren', [5, 9, 100]])
expect(BackgroundMigrationWorker.jobs[1]['at']).to eq(RetryBackfillTraversalIds::DELAY_INTERVAL.from_now.to_f)
end
end
end
end

2
spec/models/concerns/has_user_type_spec.rb
View File

@ -5,7 +5,7 @@ require 'spec_helper'
RSpec.describe User do
specify 'types consistency checks', :aggregate_failures do
expect(described_class::USER_TYPES.keys)
.to match_array(%w[human ghost alert_bot project_bot support_bot service_user security_bot visual_review_bot migration_bot])
.to match_array(%w[human ghost alert_bot project_bot support_bot service_user security_bot visual_review_bot migration_bot automation_bot])
expect(described_class::USER_TYPES).to include(*described_class::BOT_USER_TYPES)
expect(described_class::USER_TYPES).to include(*described_class::NON_INTERNAL_USER_TYPES)
expect(described_class::USER_TYPES).to include(*described_class::INTERNAL_USER_TYPES)

94
spec/models/concerns/token_authenticatable_strategies/encryption_helper_spec.rb
View File

@ -3,25 +3,99 @@
require 'spec_helper'
RSpec.describe TokenAuthenticatableStrategies::EncryptionHelper do
let(:encrypted_token) { described_class.encrypt_token('my-value') }
let(:encrypted_token) { described_class.encrypt_token('my-value-my-value-my-value') }
describe '.encrypt_token' do
it 'encrypts token' do
expect(encrypted_token).not_to eq('my-value')
context 'when dynamic_nonce feature flag is switched on' do
it 'adds nonce identifier on the beginning' do
expect(encrypted_token.first).to eq(described_class::DYNAMIC_NONCE_IDENTIFIER)
end
it 'adds nonce at the end' do
nonce = encrypted_token.last(described_class::NONCE_SIZE)
expect(nonce).to eq(::Digest::SHA256.hexdigest('my-value-my-value-my-value').bytes.take(described_class::NONCE_SIZE).pack('c*'))
end
it 'encrypts token' do
expect(encrypted_token[1...-described_class::NONCE_SIZE]).not_to eq('my-value-my-value-my-value')
end
end
context 'when dynamic_nonce feature flag is switched off' do
before do
stub_feature_flags(dynamic_nonce: false)
end
it 'does not add nonce identifier on the beginning' do
expect(encrypted_token.first).not_to eq(described_class::DYNAMIC_NONCE_IDENTIFIER)
end
it 'does not add nonce in the end' do
nonce = encrypted_token.last(described_class::NONCE_SIZE)
expect(nonce).not_to eq(::Digest::SHA256.hexdigest('my-value-my-value-my-value').bytes.take(described_class::NONCE_SIZE).pack('c*'))
end
it 'encrypts token with static iv' do
token = Gitlab::CryptoHelper.aes256_gcm_encrypt('my-value-my-value-my-value')
expect(encrypted_token).to eq(token)
end
end
end
describe '.decrypt_token' do
it 'decrypts token with static iv' do
expect(described_class.decrypt_token(encrypted_token)).to eq('my-value')
context 'with feature flag switched off' do
before do
stub_feature_flags(dynamic_nonce: false)
end
it 'decrypts token with static iv' do
encrypted_token = described_class.encrypt_token('my-value')
expect(described_class.decrypt_token(encrypted_token)).to eq('my-value')
end
it 'decrypts token if feature flag changed after encryption' do
encrypted_token = described_class.encrypt_token('my-value')
expect(encrypted_token).not_to eq('my-value')
stub_feature_flags(dynamic_nonce: true)
expect(described_class.decrypt_token(encrypted_token)).to eq('my-value')
end
it 'decrypts token with dynamic iv' do
iv = ::Digest::SHA256.hexdigest('my-value').bytes.take(described_class::NONCE_SIZE).pack('c*')
token = Gitlab::CryptoHelper.aes256_gcm_encrypt('my-value', nonce: iv)
encrypted_token = "#{described_class::DYNAMIC_NONCE_IDENTIFIER}#{token}#{iv}"
expect(described_class.decrypt_token(encrypted_token)).to eq('my-value')
end
end
it 'decrypts token with dynamic iv' do
iv = ::Digest::SHA256.hexdigest('my-value').bytes.take(described_class::NONCE_SIZE).pack('c*')
token = Gitlab::CryptoHelper.aes256_gcm_encrypt('my-value', nonce: iv)
encrypted_token = "#{described_class::DYNAMIC_NONCE_IDENTIFIER}#{token}#{iv}"
context 'with feature flag switched on' do
before do
stub_feature_flags(dynamic_nonce: true)
end
expect(described_class.decrypt_token(encrypted_token)).to eq('my-value')
it 'decrypts token with dynamic iv' do
encrypted_token = described_class.encrypt_token('my-value')
expect(described_class.decrypt_token(encrypted_token)).to eq('my-value')
end
it 'decrypts token if feature flag changed after encryption' do
encrypted_token = described_class.encrypt_token('my-value')
expect(encrypted_token).not_to eq('my-value')
stub_feature_flags(dynamic_nonce: false)
expect(described_class.decrypt_token(encrypted_token)).to eq('my-value')
end
end
end
end

41
spec/models/milestone_spec.rb
View File

@ -8,7 +8,46 @@ RSpec.describe Milestone do
let(:milestone) { create(:milestone, project: project) }
let(:project) { create(:project, :public) }
it_behaves_like 'a timebox', :milestone
it_behaves_like 'a timebox', :milestone do
describe "#uniqueness_of_title" do
context "per project" do
it "does not accept the same title in a project twice" do
new_timebox = timebox.dup
expect(new_timebox).not_to be_valid
end
it "accepts the same title in another project" do
project = create(:project)
new_timebox = timebox.dup
new_timebox.project = project
expect(new_timebox).to be_valid
end
end
context "per group" do
let(:timebox) { create(:milestone, *timebox_args, group: group) }
before do
project.update!(group: group)
end
it "does not accept the same title in a group twice" do
new_timebox = described_class.new(group: group, title: timebox.title)
expect(new_timebox).not_to be_valid
end
it "does not accept the same title of a child project timebox" do
create(:milestone, *timebox_args, project: group.projects.first)
new_timebox = described_class.new(group: group, title: timebox.title)
expect(new_timebox).not_to be_valid
end
end
end
end
describe 'MilestoneStruct#serializable_hash' do
let(:predefined_milestone) { described_class::TimeboxStruct.new('Test Milestone', '#test', 1) }

9
spec/models/user_spec.rb
View File

@ -5248,9 +5248,10 @@ RSpec.describe User do
let_it_be(:user3) { create(:user, :ghost) }
let_it_be(:user4) { create(:user, user_type: :support_bot) }
let_it_be(:user5) { create(:user, state: 'blocked', user_type: :support_bot) }
let_it_be(:user6) { create(:user, user_type: :automation_bot) }
it 'returns all active users including active bots but ghost users' do
expect(described_class.active_without_ghosts).to match_array([user1, user4])
expect(described_class.active_without_ghosts).to match_array([user1, user4, user6])
end
end
@ -5385,7 +5386,8 @@ RSpec.describe User do
{ user_type: :ghost },
{ user_type: :alert_bot },
{ user_type: :support_bot },
{ user_type: :security_bot }
{ user_type: :security_bot },
{ user_type: :automation_bot }
]
end
@ -5441,6 +5443,7 @@ RSpec.describe User do
'alert_bot' | false
'support_bot' | false
'security_bot' | false
'automation_bot' | false
end
with_them do
@ -5588,10 +5591,12 @@ RSpec.describe User do
it_behaves_like 'bot users', :migration_bot
it_behaves_like 'bot users', :security_bot
it_behaves_like 'bot users', :ghost
it_behaves_like 'bot users', :automation_bot
it_behaves_like 'bot user avatars', :alert_bot, 'alert-bot.png'
it_behaves_like 'bot user avatars', :support_bot, 'support-bot.png'
it_behaves_like 'bot user avatars', :security_bot, 'security-bot.png'
it_behaves_like 'bot user avatars', :automation_bot, 'support-bot.png'
context 'when bot is the support_bot' do
subject { described_class.support_bot }

Some files were not shown because too many files have changed in this diff Show More