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 2024-09-11 09:07:59 +00:00
parent 842a565144
commit 4e5102beb2
82 changed files with 1210 additions and 1421 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

98
app/assets/javascripts/sessions/new/components/email_form.vue Normal file
View File

@ -0,0 +1,98 @@
<script>
import { GlForm, GlFormGroup, GlFormInput, GlButton } from '@gitlab/ui';
import { isUserEmail } from '~/lib/utils/forms';
import { I18N_EMAIL, I18N_CANCEL, I18N_EMAIL_INVALID } from '../constants';
export default {
components: {
GlForm,
GlFormGroup,
GlFormInput,
GlButton,
},
props: {
error: {
type: String,
required: false,
default: '',
},
formInfo: {
type: String,
required: false,
default: undefined,
},
submitText: {
type: String,
required: true,
},
},
data() {
return {
email: '',
submitted: false,
};
},
computed: {
inputValidation() {
return {
state: !(this.submitted && this.invalidFeedback),
message: this.invalidFeedback,
};
},
invalidFeedback() {
if (!this.submitted) {
return '';
}
if (!isUserEmail(this.email)) {
return I18N_EMAIL_INVALID;
}
return this.error;
},
},
watch: {
email() {
this.submitted = false;
},
},
methods: {
submit() {
this.submitted = true;
this.$emit('submit-email', this.email);
},
},
i18n: {
email: I18N_EMAIL,
cancel: I18N_CANCEL,
},
};
</script>
<template>
<gl-form @submit.prevent="submit">
<gl-form-group
:label="$options.i18n.email"
label-for="email-input"
:state="inputValidation.state"
:invalid-feedback="inputValidation.message"
>
<gl-form-input
id="email-input"
v-model="email"
type="email"
autofocus
:state="inputValidation.state"
/>
<p v-if="formInfo" class="gl-mt-3 gl-text-secondary">{{ formInfo }}</p>
</gl-form-group>
<section class="gl-mt-5">
<gl-button block variant="confirm" type="submit" :disabled="!inputValidation.state">{{
submitText
}}</gl-button>
<gl-button block variant="link" class="gl-mt-3 gl-h-7" @click="$emit('cancel')">{{
$options.i18n.cancel
}}</gl-button>
</section>
</gl-form>
</template>

10
app/assets/javascripts/sessions/new/components/email_verification.vue
View File

@ -50,10 +50,6 @@ export default {
type: Boolean,
required: true,
},
updateEmailPath: {
type: String,
required: true,
},
},
data() {
return {
@ -164,11 +160,7 @@ export default {
<template>
<div>
<update-email
v-if="showUpdateEmail"
:update-email-path="updateEmailPath"
@verifyToken="verifyToken"
/>
<update-email v-if="showUpdateEmail" @verifyToken="verifyToken" />
<gl-form v-else @submit.prevent="verify">
<section class="gl-mb-5">
<gl-sprintf :message="$options.i18n.explanation">

88
app/assets/javascripts/sessions/new/components/update_email.vue
View File

@ -1,73 +1,33 @@
<script>
import { GlForm, GlFormGroup, GlFormInput, GlButton } from '@gitlab/ui';
import { createAlert, VARIANT_SUCCESS } from '~/alert';
import { isUserEmail } from '~/lib/utils/forms';
import axios from '~/lib/utils/axios_utils';
import {
I18N_EMAIL,
I18N_UPDATE_EMAIL,
I18N_UPDATE_EMAIL_GUIDANCE,
I18N_CANCEL,
I18N_EMAIL_INVALID,
I18N_UPDATE_EMAIL_SUCCESS,
I18N_GENERIC_ERROR,
SUCCESS_RESPONSE,
FAILURE_RESPONSE,
} from '../constants';
import EmailForm from './email_form.vue';
export default {
name: 'UpdateEmail',
components: {
GlForm,
GlFormGroup,
GlFormInput,
GlButton,
},
props: {
updateEmailPath: {
type: String,
required: true,
},
},
components: { EmailForm },
inject: ['updateEmailPath'],
data() {
return {
email: '',
submitted: false,
verifyError: '',
};
},
computed: {
inputValidation() {
return {
state: !(this.submitted && this.invalidFeedback),
message: this.invalidFeedback,
};
},
invalidFeedback() {
if (!this.submitted) {
return '';
}
if (!isUserEmail(this.email)) {
return I18N_EMAIL_INVALID;
}
return this.verifyError;
},
},
watch: {
email() {
this.verifyError = '';
},
},
methods: {
updateEmail() {
this.submitted = true;
if (!this.inputValidation.state) return;
updateEmail(email) {
this.verifyError = '';
this.email = email;
axios
.patch(this.updateEmailPath, { user: { email: this.email } })
.patch(this.updateEmailPath, { user: { email } })
.then(this.handleResponse)
.catch(this.handleError);
},
@ -96,38 +56,18 @@ export default {
},
},
i18n: {
email: I18N_EMAIL,
updateEmail: I18N_UPDATE_EMAIL,
cancel: I18N_CANCEL,
guidance: I18N_UPDATE_EMAIL_GUIDANCE,
},
};
</script>
<template>
<gl-form novalidate @submit.prevent="updateEmail">
<gl-form-group
:label="$options.i18n.email"
label-for="update-email"
:state="inputValidation.state"
:invalid-feedback="inputValidation.message"
>
<gl-form-input
id="update-email"
v-model="email"
type="email"
autofocus
:state="inputValidation.state"
/>
<p class="gl-mt-3 gl-text-secondary">{{ $options.i18n.guidance }}</p>
</gl-form-group>
<section class="gl-mt-5">
<gl-button block variant="confirm" type="submit" :disabled="!inputValidation.state">{{
$options.i18n.updateEmail
}}</gl-button>
<gl-button block variant="link" class="gl-mt-3 gl-h-7" @click="$emit('verifyToken')">{{
$options.i18n.cancel
}}</gl-button>
</section>
</gl-form>
<email-form
:error="verifyError"
:form-info="$options.i18n.guidance"
:submit-text="$options.i18n.updateEmail"
@submit-email="updateEmail"
@cancel="() => $emit('verifyToken')"
/>
</template>

2
app/assets/javascripts/sessions/new/index.js
View File

@ -15,6 +15,7 @@ export default () => {
return new Vue({
el,
name: 'EmailVerificationRoot',
provide: { updateEmailPath },
render(createElement) {
return createElement(EmailVerification, {
props: {
@ -23,7 +24,6 @@ export default () => {
verifyPath,
resendPath,
isOfferEmailReset: parseBoolean(offerEmailReset),
updateEmailPath,
},
});
},

24
app/services/issuable_base_service.rb
View File

@ -332,6 +332,7 @@ class IssuableBaseService < ::BaseContainerService
GraphqlTriggers.issuable_description_updated(issuable)
end
# rubocop:disable Metrics/AbcSize -- Method is only slightly over the limit due to decomposition method
def update(issuable)
::Gitlab::Database::LoadBalancing::Session.current.use_primary!
@ -387,11 +388,23 @@ class IssuableBaseService < ::BaseContainerService
invalidate_cache_counts(issuable, users: affected_assignees.compact)
after_update(issuable, old_associations)
issuable.create_new_cross_references!(current_user)
execute_hooks(
issuable,
'update',
old_associations: old_associations
)
Gitlab::Database::QueryAnalyzers::PreventCrossDatabaseModification.temporary_ignore_tables_in_transaction(
%w[
internal_ids
issues
issue_user_mentions
issue_metrics
notes
system_note_metadata
vulnerability_issue_links
], url: 'https://gitlab.com/gitlab-org/gitlab/-/issues/480369'
) do
execute_hooks(
issuable,
'update',
old_associations: old_associations
)
end
issuable.update_project_counter_caches if update_project_counters
end
@ -401,6 +414,7 @@ class IssuableBaseService < ::BaseContainerService
issuable
end
# rubocop:enable Metrics/AbcSize
# Overriden in child class
def trigger_update_subscriptions(issuable, old_associations); end

2
app/services/loose_foreign_keys/batch_cleaner_service.rb
View File

@ -88,7 +88,7 @@ module LooseForeignKeys
def record_result(cleaner, result)
if cleaner.async_delete?
modification_tracker.add_deletions(result[:table], result[:affected_rows])
elsif cleaner.async_nullify?
elsif cleaner.async_nullify? || (cleaner.update_column_to? && Feature.enabled?(:loose_foreign_keys_update_column_to, Feature.current_request))
modification_tracker.add_updates(result[:table], result[:affected_rows])
else
logger.error("Invalid on_delete argument for definition: #{result[:table]}")

19
app/services/loose_foreign_keys/cleaner_service.rb
View File

@ -28,6 +28,10 @@ module LooseForeignKeys
loose_foreign_key_definition.on_delete == :async_nullify
end
def update_column_to?
loose_foreign_key_definition.on_delete == :update_column_to
end
private
attr_reader :loose_foreign_key_definition, :connection, :deleted_parent_records, :with_skip_locked, :logger
@ -37,6 +41,8 @@ module LooseForeignKeys
delete_query
elsif async_nullify?
update_query
elsif update_column_to? && Feature.enabled?(:loose_foreign_keys_update_column_to, Feature.current_request)
update_target_column_query
else
logger.error("Invalid on_delete argument: #{loose_foreign_key_definition.on_delete}")
return ""
@ -77,6 +83,19 @@ module LooseForeignKeys
add_in_query_with_limit(query, UPDATE_LIMIT)
end
def update_target_column_query
column, value = loose_foreign_key_definition.options.values_at(:target_column, :target_value)
query = Arel::UpdateManager.new
query.table(quoted_table_name)
query.set([[arel_table[column], value]])
columns = Arel::Nodes::Grouping.new(primary_keys)
in_query = in_query_with_limit(UPDATE_LIMIT)
in_query.where(arel_table[column].not_eq(value))
query.where(columns.in(in_query)).to_sql
end
# IN query with one or composite primary key
# WHERE (primary_key1, primary_key2) IN (subselect)
def add_in_query_with_limit(query, limit)

2
app/views/projects/pages/_access.html.haml
View File

@ -1,8 +1,6 @@
- if @project.pages_deployed?
- pages_url = build_pages_url(@project, with_unique_domain: true)
- pages_url_text = pages_url
- if Gitlab.config.pages.namespace_in_path
- pages_url_text = "#{pages_url} (Beta)"
= render ::Layouts::CrudComponent.new(s_('GitLabPages|Access pages'),
icon: 'doc-text',

9
config/feature_flags/gitlab_com_derisk/loose_foreign_keys_update_column_to.yml Normal file
View File

@ -0,0 +1,9 @@
---
name: loose_foreign_keys_update_column_to
feature_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/475204
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/164508
rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/482775
milestone: '17.4'
group: group::package registry
type: gitlab_com_derisk
default_enabled: false

14
config/gitlab_loose_foreign_keys.yml
View File

@ -204,6 +204,9 @@ dast_profiles_tags:
- table: tags
column: tag_id
on_delete: async_delete
- table: projects
column: project_id
on_delete: async_delete
dast_scanner_profiles:
- table: projects
column: project_id
@ -242,6 +245,10 @@ dast_sites:
- table: projects
column: project_id
on_delete: async_delete
dependency_list_exports:
- table: ci_pipelines
column: pipeline_id
on_delete: async_delete
deployment_clusters:
- table: clusters
column: cluster_id
@ -573,6 +580,13 @@ vulnerability_identifiers:
- table: projects
column: project_id
on_delete: async_delete
vulnerability_issue_links:
- table: projects
column: project_id
on_delete: async_delete
- table: issues
column: issue_id
on_delete: async_delete
vulnerability_merge_request_links:
- table: projects
column: project_id

11
db/docs/batched_background_migrations/backfill_project_id_to_dependency_list_exports.yml Normal file
View File

@ -0,0 +1,11 @@
---
migration_job_name: BackfillProjectIdToDependencyListExports
description: Backfill `pipeline.project_id` to `dependency_list_export.project_id`
feature_category: dependency_management
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/164399
milestone: '17.4'
queued_migration_version: 20240829182925
# Dependency list exports are scheduled for deletion 1 hour after they finish,
# so the table will be small on all instances. We can finalize the migration in 17.5.
finalize_after: '2024-09-19'
finalized_by: # version of the migration that finalized this BBM

2
db/docs/dast_profiles_tags.yml
View File

@ -7,7 +7,7 @@ feature_categories:
description: Join Table for Runner tags and DAST Profiles
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/108371
milestone: '15.8'
gitlab_schema: gitlab_main_cell
gitlab_schema: gitlab_sec
allow_cross_foreign_keys:
- gitlab_main_clusterwide
desired_sharding_key:

10
db/docs/dependency_list_exports.yml
View File

@ -8,4 +8,12 @@ description: Dependency list exported data
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/104361
milestone: '15.7'
gitlab_schema: gitlab_main_cell
sharding_key_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/454947
desired_sharding_key_migration_job_name: BackfillProjectIdToDependencyListExports
# When migration is finalized, sharding keys should be defined as:
#
# sharding_key:
# project_id: projects
# group_id: namespaces
# organization_id: organizations
#
# A multi-column not-null constraint should be added on these columns.

12
db/docs/p_ci_job_annotations.yml
View File

@ -9,13 +9,5 @@ description: Stores user provided annotations for jobs. Currently storing extra
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/117319
milestone: '16.1'
gitlab_schema: gitlab_ci
desired_sharding_key:
project_id:
references: projects
backfill_via:
parent:
foreign_key: job_id
table: p_ci_builds
sharding_key: project_id
belongs_to: job
foreign_key_name: fk_rails_d4d0c0fa0f
sharding_key:
project_id: projects

4
db/docs/vulnerability_issue_links.yml
View File

@ -7,9 +7,7 @@ feature_categories:
description: Join table between Vulnerabilities and Issues
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/19852
milestone: '12.5'
gitlab_schema: gitlab_main_cell
allow_cross_foreign_keys:
- gitlab_main_clusterwide
gitlab_schema: gitlab_sec
desired_sharding_key:
project_id:
references: projects

15
db/migrate/20240816102041_add_lfk_triggers_to_issues.rb Normal file
View File

@ -0,0 +1,15 @@
# frozen_string_literal: true
class AddLfkTriggersToIssues < Gitlab::Database::Migration[2.2]
include Gitlab::Database::MigrationHelpers::LooseForeignKeyHelpers
milestone '17.4'
def up
track_record_deletions(:issues)
end
def down
untrack_record_deletions(:issues)
end
end

17
db/migrate/20240904133620_add_spp_repository_pipeline_access_cascading_setting.rb Normal file
View File

@ -0,0 +1,17 @@
# frozen_string_literal: true
class AddSppRepositoryPipelineAccessCascadingSetting < Gitlab::Database::Migration[2.2]
include Gitlab::Database::MigrationHelpers::CascadingNamespaceSettings
enable_lock_retries!
milestone '17.4'
def up
add_cascading_namespace_setting :spp_repository_pipeline_access, :boolean, default: false, null: false
end
def down
remove_cascading_namespace_setting :spp_repository_pipeline_access
end
end

2
db/post_migrate/20240604145223_queue_backfill_dast_profiles_tags_project_id.rb
View File

@ -2,7 +2,7 @@
class QueueBackfillDastProfilesTagsProjectId < Gitlab::Database::Migration[2.2]
milestone '17.1'
restrict_gitlab_migration gitlab_schema: :gitlab_main_cell
restrict_gitlab_migration gitlab_schema: :gitlab_sec
MIGRATION = "BackfillDastProfilesTagsProjectId"
DELAY_INTERVAL = 2.minutes

2
db/post_migrate/20240613064362_queue_backfill_vulnerability_issue_links_project_id.rb
View File

@ -2,7 +2,7 @@
class QueueBackfillVulnerabilityIssueLinksProjectId < Gitlab::Database::Migration[2.2]
milestone '17.1'
restrict_gitlab_migration gitlab_schema: :gitlab_main_cell
restrict_gitlab_migration gitlab_schema: :gitlab_sec
MIGRATION = "BackfillVulnerabilityIssueLinksProjectId"
DELAY_INTERVAL = 2.minutes

21
db/post_migrate/20240816100740_remove_issues_vulnerability_issue_links_issue_id_fk.rb Normal file
View File

@ -0,0 +1,21 @@
# frozen_string_literal: true
class RemoveIssuesVulnerabilityIssueLinksIssueIdFk < Gitlab::Database::Migration[2.2]
milestone '17.4'
disable_ddl_transaction!
FOREIGN_KEY_NAME = "fk_rails_e9180d534b"
def up
with_lock_retries do
remove_foreign_key_if_exists(:vulnerability_issue_links, :issues,
name: FOREIGN_KEY_NAME, reverse_lock_order: true)
end
end
def down
add_concurrent_foreign_key(:vulnerability_issue_links, :issues,
name: FOREIGN_KEY_NAME, column: :issue_id,
target_column: :id, on_delete: :cascade)
end
end

21
db/post_migrate/20240816103414_remove_projects_vulnerability_issue_links_project_id_fk.rb Normal file
View File

@ -0,0 +1,21 @@
# frozen_string_literal: true
class RemoveProjectsVulnerabilityIssueLinksProjectIdFk < Gitlab::Database::Migration[2.2]
milestone '17.4'
disable_ddl_transaction!
FOREIGN_KEY_NAME = "fk_081e11030b"
def up
with_lock_retries do
remove_foreign_key_if_exists(:vulnerability_issue_links, :projects,
name: FOREIGN_KEY_NAME, reverse_lock_order: true)
end
end
def down
add_concurrent_foreign_key(:vulnerability_issue_links, :projects,
name: FOREIGN_KEY_NAME, column: :project_id,
target_column: :id, on_delete: :cascade)
end
end

21
db/post_migrate/20240829141641_remove_projects_dast_profiles_tags_project_id_fk.rb Normal file
View File

@ -0,0 +1,21 @@
# frozen_string_literal: true
class RemoveProjectsDastProfilesTagsProjectIdFk < Gitlab::Database::Migration[2.2]
milestone '17.4'
disable_ddl_transaction!
FOREIGN_KEY_NAME = "fk_eb7e19f8da"
def up
with_lock_retries do
remove_foreign_key_if_exists(:dast_profiles_tags, :projects,
name: FOREIGN_KEY_NAME, reverse_lock_order: true)
end
end
def down
add_concurrent_foreign_key(:dast_profiles_tags, :projects,
name: FOREIGN_KEY_NAME, column: :project_id,
target_column: :id, on_delete: :cascade)
end
end

26
db/post_migrate/20240829182925_queue_backfill_project_id_to_dependency_list_exports.rb Normal file
View File

@ -0,0 +1,26 @@
# frozen_string_literal: true
class QueueBackfillProjectIdToDependencyListExports < Gitlab::Database::Migration[2.2]
milestone '17.4'
restrict_gitlab_migration gitlab_schema: :gitlab_main
MIGRATION = "BackfillProjectIdToDependencyListExports"
DELAY_INTERVAL = 2.minutes
BATCH_SIZE = 1_000
SUB_BATCH_SIZE = 100
def up
queue_batched_background_migration(
MIGRATION,
:dependency_list_exports,
:id,
job_interval: DELAY_INTERVAL,
batch_size: BATCH_SIZE,
sub_batch_size: SUB_BATCH_SIZE
)
end
def down
delete_batched_background_migration(MIGRATION, :dependency_list_exports, :id, [])
end
end

29
db/post_migrate/20240905022445_add_personal_namespace_id_to_events_2.rb Normal file
View File

@ -0,0 +1,29 @@
# frozen_string_literal: true
class AddPersonalNamespaceIdToEvents2 < Gitlab::Database::Migration[2.2]
milestone '17.4'
disable_ddl_transaction!
# rubocop:disable Migration/SchemaAdditionMethodsNoPost -- https://gitlab.com/gitlab-org/gitlab/-/merge_requests/165127#note_2092878736
def up
return unless Gitlab.com_except_jh?
return if column_exists?(:events, :personal_namespace_id)
with_lock_retries(raise_on_exhaustion: true) do
add_column :events, :personal_namespace_id, :bigint
end
end
def down
return unless Gitlab.com_except_jh?
return unless column_exists?(:events, :personal_namespace_id)
with_lock_retries(raise_on_exhaustion: true) do
remove_column :events, :personal_namespace_id
end
end
# rubocop:enable Migration/SchemaAdditionMethodsNoPost
end

22
db/post_migrate/20240905023750_async_add_index_on_events_personal_namespace_id_2.rb Normal file
View File

@ -0,0 +1,22 @@
# frozen_string_literal: true
class AsyncAddIndexOnEventsPersonalNamespaceId2 < Gitlab::Database::Migration[2.2]
milestone '17.4'
INDEX_NAME = 'index_events_on_personal_namespace_id'
# rubocop:disable Migration/PreventIndexCreation -- https://gitlab.com/gitlab-org/gitlab/-/issues/462801#note_2081632603
def up
return unless Gitlab.com_except_jh?
prepare_async_index :events, :personal_namespace_id, name: INDEX_NAME,
where: 'personal_namespace_id IS NOT NULL'
end
# rubocop:enable Migration/PreventIndexCreation
def down
return unless Gitlab.com_except_jh?
unprepare_async_index :events, INDEX_NAME
end
end

1
db/schema_migrations/20240816100740 Normal file
View File

@ -0,0 +1 @@
dd6aa164b7968a877d987bb0a6febf1e6a66090c143a3dd9ee4d44d21bde62ad

1
db/schema_migrations/20240816102041 Normal file
View File

@ -0,0 +1 @@
ff19147e8d4c0b4e5b148180e1291eedc5bfd0d56ab0c2281283a66fd4a0eae4

1
db/schema_migrations/20240816103414 Normal file
View File

@ -0,0 +1 @@
f6735bba437449da06fc37c50af083306afe23b1ba97209adbf633d4784fc5e8

1
db/schema_migrations/20240829141641 Normal file
View File

@ -0,0 +1 @@
268296714ea9b530baa45c2932daf4a26026eb5f71ad00a2dec785666da09948

1
db/schema_migrations/20240829182925 Normal file
View File

@ -0,0 +1 @@
1bfc5355a23cc0a072acde28109ee0a9e6f3c788673d7f4040e015ed69a0f564

1
db/schema_migrations/20240904133620 Normal file
View File

@ -0,0 +1 @@
aed6ac3aedb4e6d09923f43c3319f30ff14e183cc931b4741defa6d217653f04

1
db/schema_migrations/20240905022445 Normal file
View File

@ -0,0 +1 @@
ba9c7d09d86a4618db752c337ba522074fb56a26f0c1c4c4f31934c85a283414

1
db/schema_migrations/20240905023750 Normal file
View File

@ -0,0 +1 @@
c2e9d545e650e4912ddc50ac304de2f84574551b588927611d686dd1879fe53c

15
db/structure.sql
View File

@ -6067,6 +6067,8 @@ CREATE TABLE application_settings (
observability_backend_ssl_verification_enabled boolean DEFAULT true NOT NULL,
pages jsonb DEFAULT '{}'::jsonb NOT NULL,
security_policies jsonb DEFAULT '{}'::jsonb NOT NULL,
spp_repository_pipeline_access boolean DEFAULT false NOT NULL,
lock_spp_repository_pipeline_access boolean DEFAULT false NOT NULL,
CONSTRAINT app_settings_container_reg_cleanup_tags_max_list_size_positive CHECK ((container_registry_cleanup_tags_service_max_list_size >= 0)),
CONSTRAINT app_settings_dep_proxy_ttl_policies_worker_capacity_positive CHECK ((dependency_proxy_ttl_group_policy_worker_capacity >= 0)),
CONSTRAINT app_settings_ext_pipeline_validation_service_url_text_limit CHECK ((char_length(external_pipeline_validation_service_url) <= 255)),
@ -13908,6 +13910,8 @@ CREATE TABLE namespace_settings (
seat_control smallint DEFAULT 0 NOT NULL,
last_dormant_member_review_at timestamp with time zone,
enterprise_users_extensions_marketplace_opt_in_status smallint DEFAULT 0 NOT NULL,
spp_repository_pipeline_access boolean,
lock_spp_repository_pipeline_access boolean DEFAULT false NOT NULL,
CONSTRAINT check_0ba93c78c7 CHECK ((char_length(default_branch_name) <= 255)),
CONSTRAINT namespace_settings_unique_project_download_limit_alertlist_size CHECK ((cardinality(unique_project_download_limit_alertlist) <= 100)),
CONSTRAINT namespace_settings_unique_project_download_limit_allowlist_size CHECK ((cardinality(unique_project_download_limit_allowlist) <= 100))
@ -32767,6 +32771,8 @@ CREATE TRIGGER ci_runners_loose_fk_trigger AFTER DELETE ON ci_runners REFERENCIN
CREATE TRIGGER clusters_loose_fk_trigger AFTER DELETE ON clusters REFERENCING OLD TABLE AS old_table FOR EACH STATEMENT EXECUTE FUNCTION insert_into_loose_foreign_keys_deleted_records();
CREATE TRIGGER issues_loose_fk_trigger AFTER DELETE ON issues REFERENCING OLD TABLE AS old_table FOR EACH STATEMENT EXECUTE FUNCTION insert_into_loose_foreign_keys_deleted_records();
CREATE TRIGGER merge_requests_loose_fk_trigger AFTER DELETE ON merge_requests REFERENCING OLD TABLE AS old_table FOR EACH STATEMENT EXECUTE FUNCTION insert_into_loose_foreign_keys_deleted_records();
CREATE TRIGGER namespaces_loose_fk_trigger AFTER DELETE ON namespaces REFERENCING OLD TABLE AS old_table FOR EACH STATEMENT EXECUTE FUNCTION insert_into_loose_foreign_keys_deleted_records();
@ -33074,9 +33080,6 @@ ALTER TABLE ONLY ai_agent_version_attachments
ALTER TABLE ONLY abuse_report_notes
ADD CONSTRAINT fk_0801b83126 FOREIGN KEY (updated_by_id) REFERENCES users(id) ON DELETE CASCADE;
ALTER TABLE ONLY vulnerability_issue_links
ADD CONSTRAINT fk_081e11030b FOREIGN KEY (project_id) REFERENCES projects(id) ON DELETE CASCADE;
ALTER TABLE ONLY analytics_cycle_analytics_stage_event_hashes
ADD CONSTRAINT fk_0839874e4f FOREIGN KEY (organization_id) REFERENCES organizations(id) ON DELETE CASCADE;
@ -34415,9 +34418,6 @@ ALTER TABLE ONLY pages_domains
ALTER TABLE ONLY packages_debian_project_distribution_keys
ADD CONSTRAINT fk_eb2224a3c0 FOREIGN KEY (project_id) REFERENCES projects(id) ON DELETE CASCADE;
ALTER TABLE ONLY dast_profiles_tags
ADD CONSTRAINT fk_eb7e19f8da FOREIGN KEY (project_id) REFERENCES projects(id) ON DELETE CASCADE;
ALTER TABLE ONLY compliance_requirements
ADD CONSTRAINT fk_ebf5c3365b FOREIGN KEY (framework_id) REFERENCES compliance_management_frameworks(id) ON DELETE CASCADE;
@ -36272,9 +36272,6 @@ ALTER TABLE ONLY audit_events_streaming_event_type_filters
ALTER TABLE ONLY description_versions
ADD CONSTRAINT fk_rails_e8f4caf9c7 FOREIGN KEY (epic_id) REFERENCES epics(id) ON DELETE CASCADE;
ALTER TABLE ONLY vulnerability_issue_links
ADD CONSTRAINT fk_rails_e9180d534b FOREIGN KEY (issue_id) REFERENCES issues(id) ON DELETE CASCADE;
ALTER TABLE ONLY merge_request_blocks
ADD CONSTRAINT fk_rails_e9387863bc FOREIGN KEY (blocking_merge_request_id) REFERENCES merge_requests(id) ON DELETE CASCADE;

27
doc/administration/pages/index.md
View File

@ -99,17 +99,10 @@ IPv6 address. If you don't have IPv6, you can omit the `AAAA` record.
#### For namespace in URL path, without wildcard DNS
DETAILS:
**Status:** Beta
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/17584) as an [experiment](../../policy/experiment-beta-support.md) in GitLab 16.7.
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/148621) to [beta](../../policy/experiment-beta-support.md) in GitLab 16.11.
> - [Changed](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/1111) implementation from NGINX to the GitLab Pages codebase in GitLab 17.2.
FLAG:
On self-managed GitLab, by default this feature is available.
On GitLab.com and GitLab Dedicated, this feature is not available.
This feature is not ready for production use.
> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/483365) in GitLab 17.4.
Prerequisites:
@ -198,17 +191,10 @@ Watch the [video tutorial](https://youtu.be/dD8c7WNcc6s) for this configuration.
### Pages domain without wildcard DNS
DETAILS:
**Status:** Beta
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/17584) as an [experiment](../../policy/experiment-beta-support.md) in GitLab 16.7.
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/148621) to [beta](../../policy/experiment-beta-support.md) in GitLab 16.11.
> - [Changed](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/1111) implementation from NGINX to the GitLab Pages codebase in GitLab 17.2.
FLAG:
On self-managed GitLab, by default this feature is available.
On GitLab.com and GitLab Dedicated, this feature is not available.
This feature is not ready for production use.
> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/483365) in GitLab 17.4.
This configuration is the minimum setup for GitLab Pages. It is the base for all
other configurations. In this configuration, NGINX proxies all requests to the daemon,
@ -289,17 +275,10 @@ then run `gitlab-ctl reconfigure`. For more information, read
### Pages domain with TLS support, without wildcard DNS
DETAILS:
**Status:** Beta
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/17584) as an [experiment](../../policy/experiment-beta-support.md) in GitLab 16.7.
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/148621) to [beta](../../policy/experiment-beta-support.md) in GitLab 16.11.
> - [Changed](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/1111) implementation from NGINX to the GitLab Pages codebase in GitLab 17.2.
FLAG:
On self-managed GitLab, by default this feature is available.
On GitLab.com and GitLab Dedicated, this feature is not available.
This feature is not ready for production use.
> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/483365) in GitLab 17.4.
Prerequisites:

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

@ -517,7 +517,11 @@ cluster to be used with GitLab.
You can optionally use a [third party external service for PostgreSQL](../../administration/postgresql/external.md).
A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default from [14.4.0](../../update/versions/gitlab_14_changes.md#1440). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal)
and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default from
[14.4.0](https://docs.gitlab.com/17.3/ee/update/versions/gitlab_14_changes.html#1440).
See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
If you use a third party external service:
@ -1297,7 +1301,11 @@ you are using Geo, where separate database instances are required for handling r
In this setup, the specs of the main database setup shouldn't need to be changed as the impact should be
minimal.
A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default in [14.4.0](../../update/versions/gitlab_14_changes.md#1440). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal)
and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default from
[14.4.0](https://docs.gitlab.com/17.3/ee/update/versions/gitlab_14_changes.html#1440).
See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
Examples of the above could include [Google's Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) or [Amazon RDS](https://aws.amazon.com/rds/).

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

@ -521,7 +521,11 @@ cluster to be used with GitLab.
You can optionally use a [third party external service for PostgreSQL](../../administration/postgresql/external.md).
A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default from [14.4.0](../../update/versions/gitlab_14_changes.md#1440). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal)
and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default from
[14.4.0](https://docs.gitlab.com/17.3/ee/update/versions/gitlab_14_changes.html#1440).
See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
If you use a third party external service:
@ -1305,7 +1309,11 @@ you are using Geo, where separate database instances are required for handling r
In this setup, the specs of the main database setup shouldn't need to be changed as the impact should be
minimal.
A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default in [14.4.0](../../update/versions/gitlab_14_changes.md#1440). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal)
and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default from
[14.4.0](https://docs.gitlab.com/17.3/ee/update/versions/gitlab_14_changes.html#1440).
See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
Once the database is set up, follow the [post configuration](#praefect-postgresql-post-configuration).

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

@ -268,7 +268,11 @@ to be used with GitLab.
You can optionally use a [third party external service for PostgreSQL](../../administration/postgresql/external.md).
A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default from [14.4.0](../../update/versions/gitlab_14_changes.md#1440). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal)
and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default from
[14.4.0](https://docs.gitlab.com/17.3/ee/update/versions/gitlab_14_changes.html#1440).
See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
If you use a third party external service:

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

@ -507,7 +507,11 @@ cluster to be used with GitLab.
You can optionally use a [third party external service for PostgreSQL](../../administration/postgresql/external.md).
A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default from [14.4.0](../../update/versions/gitlab_14_changes.md#1440). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal)
and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default from
[14.4.0](https://docs.gitlab.com/17.3/ee/update/versions/gitlab_14_changes.html#1440).
See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
If you use a third party external service:
@ -1135,7 +1139,11 @@ you are using Geo, where separate database instances are required for handling r
In this setup, the specs of the main database setup shouldn't need to be changed as the impact should be
minimal.
A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default in [14.4.0](../../update/versions/gitlab_14_changes.md#1440). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal)
and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default from
[14.4.0](https://docs.gitlab.com/17.3/ee/update/versions/gitlab_14_changes.html#1440).
See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
Once the database is set up, follow the [post configuration](#praefect-postgresql-post-configuration).

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

@ -525,7 +525,11 @@ cluster to be used with GitLab.
You can optionally use a [third party external service for PostgreSQL](../../administration/postgresql/external.md).
A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default from [14.4.0](../../update/versions/gitlab_14_changes.md#1440). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal)
and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default from
[14.4.0](https://docs.gitlab.com/17.3/ee/update/versions/gitlab_14_changes.html#1440).
See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
If you use a third party external service:
@ -1312,7 +1316,9 @@ you are using Geo, where separate database instances are required for handling r
In this setup, the specs of the main database setup shouldn't need to be changed as the impact should be
minimal.
A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default in [14.4.0](../../update/versions/gitlab_14_changes.md#1440). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal)
and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default from
[14.4.0](https://docs.gitlab.com/17.3/ee/update/versions/gitlab_14_changes.html#1440).
Examples of the above could include [Google's Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) or [Amazon RDS](https://aws.amazon.com/rds/).

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

@ -507,7 +507,11 @@ cluster to be used with GitLab.
You can optionally use a [third party external service for PostgreSQL](../../administration/postgresql/external.md).
A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default from [14.4.0](../../update/versions/gitlab_14_changes.md#1440). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal)
and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default from
[14.4.0](https://docs.gitlab.com/17.3/ee/update/versions/gitlab_14_changes.html#1440).
See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
If you use a third party external service:
@ -1136,7 +1140,11 @@ you are using Geo, where separate database instances are required for handling r
In this setup, the specs of the main database setup shouldn't need to be changed as the impact should be
minimal.
A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default in [14.4.0](../../update/versions/gitlab_14_changes.md#1440). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
A reputable provider or solution should be used for this. [Google Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal)
and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon Aurora is **incompatible** with load balancing enabled by default from
[14.4.0](https://docs.gitlab.com/17.3/ee/update/versions/gitlab_14_changes.html#1440).
See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
Once the database is set up, follow the [post configuration](#praefect-postgresql-post-configuration).

2
doc/administration/reference_architectures/index.md
View File

@ -433,7 +433,7 @@ If you choose to use a third party external service:
Several database cloud provider services are known not to support the above or have been found to have other issues and aren't recommended:
- [Amazon Aurora](https://aws.amazon.com/rds/aurora/) is incompatible and not supported. See [14.4.0](../../update/versions/gitlab_14_changes.md#1440) for more details.
- [Amazon Aurora](https://aws.amazon.com/rds/aurora/) is incompatible and not supported. See [14.4.0](https://docs.gitlab.com/17.3/ee/update/versions/gitlab_14_changes.html#1440) for more details.
- [Azure Database for PostgreSQL Single Server](https://azure.microsoft.com/en-gb/products/postgresql/#overview) is not supported as the service is now deprecated and runs on an unsupported version of PostgreSQL. It was also found to have notable performance and stability issues.
- [Google AlloyDB](https://cloud.google.com/alloydb) and [Amazon RDS Multi-AZ DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html) have not been tested and are not recommended. Both solutions are specifically not expected to work with GitLab Geo.
- [Amazon RDS Multi-AZ DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html) is a separate product and is supported.

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

@ -19874,7 +19874,7 @@ Represents a ComplianceFramework associated with a Project.
| <a id="complianceframeworkdescription"></a>`description` | [`String!`](#string) | Description of the compliance framework. |
| <a id="complianceframeworkid"></a>`id` | [`ID!`](#id) | Compliance framework ID. |
| <a id="complianceframeworkname"></a>`name` | [`String!`](#string) | Name of the compliance framework. |
| <a id="complianceframeworkpipelineconfigurationfullpath"></a>`pipelineConfigurationFullPath` | [`String`](#string) | Full path of the compliance pipeline configuration stored in a project repository, such as `.gitlab/.compliance-gitlab-ci.yml@compliance/hipaa`. Ultimate only. |
| <a id="complianceframeworkpipelineconfigurationfullpath"></a>`pipelineConfigurationFullPath` **{warning-solid}** | [`String`](#string) | **Deprecated** in GitLab 17.4. Use pipeline execution policies instead. |
| <a id="complianceframeworkprojects"></a>`projects` | [`ProjectConnection`](#projectconnection) | Projects associated with the compliance framework. (see [Connections](#connections)) |
| <a id="complianceframeworkscanexecutionpolicies"></a>`scanExecutionPolicies` | [`ScanExecutionPolicyConnection`](#scanexecutionpolicyconnection) | Scan Execution Policies of the compliance framework. (see [Connections](#connections)) |
| <a id="complianceframeworkscanresultpolicies"></a>`scanResultPolicies` | [`ScanResultPolicyConnection`](#scanresultpolicyconnection) | Scan Result Policies of the compliance framework. (see [Connections](#connections)) |
@ -41221,7 +41221,7 @@ Attributes for defining a CI/CD variable.
| <a id="complianceframeworkinputdefault"></a>`default` | [`Boolean`](#boolean) | Set this compliance framework as the default framework for the group. |
| <a id="complianceframeworkinputdescription"></a>`description` | [`String`](#string) | New description for the compliance framework. |
| <a id="complianceframeworkinputname"></a>`name` | [`String`](#string) | New name for the compliance framework. |
| <a id="complianceframeworkinputpipelineconfigurationfullpath"></a>`pipelineConfigurationFullPath` | [`String`](#string) | Full path of the compliance pipeline configuration stored in a project repository, such as `.gitlab/.compliance-gitlab-ci.yml@compliance/hipaa`. Ultimate only. |
| <a id="complianceframeworkinputpipelineconfigurationfullpath"></a>`pipelineConfigurationFullPath` **{warning-solid}** | [`String`](#string) | **Deprecated:** Use pipeline execution policies instead. Deprecated in GitLab 17.4. |
### `ComplianceStandardsAdherenceInput`

10
doc/api/group_saml_group_links.md
View File

@ -4,7 +4,7 @@ group: Authentication
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
---
## SAML group links API
# SAML group links API
DETAILS:
**Tier:** Premium, Ultimate
@ -18,7 +18,7 @@ DETAILS:
List, get, add, and delete [SAML group links](../user/group/saml_sso/group_sync.md#configure-saml-group-links) by using
the REST API.
### List SAML group links
## List SAML group links
List SAML group links for a group.
@ -63,7 +63,7 @@ Example response:
]
```
### Get a SAML group link
## Get a SAML group link
Get a SAML group link for a group.
@ -102,7 +102,7 @@ Example response:
}
```
### Add a SAML group link
## Add a SAML group link
Add a SAML group link for a group.
@ -143,7 +143,7 @@ Example response:
}
```
### Delete a SAML group link
## Delete a SAML group link
Delete a SAML group link for a group.

105
doc/api/user_service_accounts.md Normal file
View File

@ -0,0 +1,105 @@
---
stage: Govern
group: Authentication
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
---
# Service account users API
DETAILS:
**Tier:** Premium, Ultimate
**Offering:** Self-managed, GitLab Dedicated
Create and list [service account](../user/profile/service_accounts.md) users by using the REST API.
## Create a service account user
> - Ability to create a service account user was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/406782) in GitLab 16.1
> - Ability to specify a username or name was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/144841) in GitLab 16.10.
Create a service account user. You can specify the account username and name. If you do not specify any attributes:
- The default name is `Service account user`.
- The username is automatically generated.
Prerequisites:
- You must be an administrator.
```plaintext
POST /service_accounts
```
Supported attributes:
| Attribute | Type | Required | Description |
|:-----------|:-------|:---------|:------------|
| `name` | string | no | Name of the user. |
| `username` | string | no | Username of the user. |
Example request:
```shell
curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/service_accounts"
```
Example response:
```json
{
"id": 57,
"username": "service_account_6018816a18e515214e0c34c2b33523fc",
"name": "Service account user"
}
```
## List all service account users
DETAILS:
**Tier:** Premium, Ultimate
**Offering:** Self-managed, GitLab Dedicated
> - Ability to list all service account users [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/416729) in GitLab 17.1.
Lists all service account users.
Prerequisites:
- You must be an administrator.
This function takes [pagination parameters](rest/index.md#offset-based-pagination) `page` and `per_page` to restrict the
list of users.
```plaintext
GET /service_accounts
```
Supported attributes:
| Attribute | Type | Required | Description |
|:-----------|:-------|:---------|:------------|
| `order_by` | string | no | Order list of users by `username` or `id` Default is `id`. |
| `sort` | string | no | Specify sorting by `asc` or `desc`. Default is `desc`. |
Example request:
```shell
curl --request GET --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/service_accounts"
```
Example response:
```json
[
{
"id": 114,
"username": "service_account_33",
"name": "Service account user"
},
{
"id": 137,
"username": "service_account_34",
"name": "john doe"
}
]
```

88
doc/api/users.md
View File

@ -1095,94 +1095,6 @@ Example response:
}
```
## Create Service Account User
DETAILS:
**Tier:** Premium, Ultimate
**Offering:** Self-managed, GitLab Dedicated
> - Ability to create a service account user was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/406782) in GitLab 16.1
> - Ability to specify a username or name was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/144841) in GitLab 16.10.
Creates a service account user. You can specify the account username and name. If you do not specify these attributes, the default name is `Service account user` and the username is automatically generated. Available only for administrators.
```plaintext
POST /service_accounts
```
```shell
curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/service_accounts"
```
Supported attributes:
| Attribute | Type | Required | Description |
|:---------------------------|:---------------|:--------------------------|:-------------------------------------------------------------------------------|
| `name` | string | no | Name of the user |
| `username` | string | no | Username of the user |
Example response:
```json
{
"id": 57,
"username": "service_account_6018816a18e515214e0c34c2b33523fc",
"name": "Service account user"
}
```
## List service account users
DETAILS:
**Tier:** Premium, Ultimate
**Offering:** Self-managed, GitLab Dedicated
> - Ability to list all service account users [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/416729) in GitLab 17.1.
Prerequisites:
- You must be an administrator of the self-managed instance.
Lists all service account users.
This function takes pagination parameters `page` and `per_page` to restrict the list of users.
This API endpoint requires the user to be an instance admin.
Example request:
```plaintext
GET /service_accounts
```
```shell
curl --request GET --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/service_accounts"
```
Supported attributes:
| Attribute | Type | Required | Description |
|:-------------|:---------|:----------|:------------------------------------------------------------|
| `order_by` | string | no | Orders list of users by `username` or `id` Default is `id`. |
| `sort` | string | no | Specifies sorting by `asc` or `desc`. Default is `desc`. |
Example response:
```json
[
{
"id": 114,
"username": "service_account_33",
"name": "Service account user"
},
{
"id": 137,
"username": "service_account_34",
"name": "john doe"
}
]
```
## List user projects
See the [list of user projects](projects.md#list-user-projects).

3
doc/ci/gitlab_google_cloud_integration/index.md
View File

@ -9,9 +9,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** GitLab.com
**Status:** Beta
This feature is in [beta](../../policy/experiment-beta-support.md).
Use the Google Cloud integration to use Google Cloud resources in GitLab projects.

3
doc/ci/runners/provision_runners_google_cloud.md
View File

@ -11,13 +11,10 @@ info: >-
DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** GitLab.com
**Status:** Beta
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/438316) in GitLab 16.10 [with a flag](../../administration/feature_flags.md) named `google_cloud_support_feature_flag`. This feature is in [beta](../../policy/experiment-beta-support.md).
> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/150472) in GitLab 17.1. Feature flag `google_cloud_support_feature_flag` removed.
This feature is in [beta](../../policy/experiment-beta-support.md).
## Creating a runner provisioned in Google Cloud
Prerequisites:

4
doc/development/database/database_lab_pgai.md
View File

@ -55,11 +55,11 @@ you can follow the steps below to configure the `pgai` Gem:
# Grab an access token: https://console.postgres.ai/gitlab/tokens
# GITLAB_USER is your GitLab handle
pgai config --dbname=gitlabhq_dblab --prefix=$GITLAB_USER --proxy=pgai-proxy
pgai config --prefix=$GITLAB_USER
# Grab the respective port values from https://console.postgres.ai/gitlab/instances
# for the instances you'll be using (in this case, for the `main` database instance)
pgai env add --alias main --id <environment-id> --port <environment-port>
pgai env add --alias main --id <environment-id> --port <environment-port> -n <database_name>
```
1. Once this one-time configuration is done, you can use `pgai connect` to connect to a particular database. For

25
doc/development/database/loose_foreign_keys.md
View File

@ -404,6 +404,31 @@ database (for example, object storage) where you might wish to use `dependent: :
see alternatives in
[Avoid `dependent: :nullify` and `dependent: :destroy` across databases](multiple_databases.md#avoid-dependent-nullify-and-dependent-destroy-across-databases).
## Update target column to a value
A loose foreign key might be used to update a target column to a value when an
entry in parent table is deleted.
It's important to add an index (if it doesn't exist yet) on
(`column`, `target_column`) to avoid any performance issues.
Any index starting with these two columns will work.
The configuration requires additional information:
- Column to be updated (`target_column`)
- Value to be set in the target column (`target_value`)
Example definition:
```yaml
packages:
- table: projects
column: project_id
on_delete: update_column_to
target_column: status
target_value: 4
```
## Risks of loose foreign keys and possible mitigations
In general, the loose foreign keys architecture is eventually consistent and

3
doc/integration/google_cloud_iam.md
View File

@ -9,13 +9,10 @@ info: To determine the technical writer assigned to the Stage/Group associated w
DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** GitLab.com
**Status:** Beta
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/141127) in GitLab 16.10 [with a flag](../administration/feature_flags.md) named `google_cloud_support_feature_flag`. This feature is in [beta](../policy/experiment-beta-support.md).
> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/150472) in GitLab 17.1. Feature flag `google_cloud_support_feature_flag` removed.
This feature is in [beta](../policy/experiment-beta-support.md).
To use Google Cloud integrations like the
[Google Artifact Management integration](../user/project/integrations/google_artifact_management.md),
you must create and configure a

2
doc/security/tokens/token_troubleshooting.md
View File

@ -107,7 +107,7 @@ This script extends the lifetime of all tokens which expire on a specified date,
- Group access tokens
- Project access tokens
The lifetimes of tokens intentionally set to expire on the specified date are also extended.
For group and project access tokens, this script only extends the lifetime of these tokens if they were given an expiration date automatically when upgrading to GitLab 16.0 or later. If a group or project access token was generated with an expiration date, or was rotated, the validity of that token is dependent on a valid membership to a resource, and therefore the token lifetime cannot be extended using this script.
To use the script:

7
doc/topics/git/commit.md
View File

@ -114,6 +114,13 @@ see [issue 373212](https://gitlab.com/gitlab-org/gitlab/-/issues/373212).
|--------------------------------|-------------|---------|
| `ci.skip` | Do not create a CI/CD pipeline for the latest push. Skips only branch pipelines and not [merge request pipelines](../../ci/pipelines/merge_request_pipelines.md). This does not skip pipelines for CI/CD integrations, such as Jenkins. | `git push -o ci.skip` |
| `ci.variable="<name>=<value>"` | Provide [CI/CD variables](../../ci/variables/index.md) to the CI/CD pipeline, if one is created due to the push. Passes variables only to branch pipelines and not [merge request pipelines](../../ci/pipelines/merge_request_pipelines.md). | `git push -o ci.variable="MAX_RETRIES=10" -o ci.variable="MAX_TIME=600"` |
### Push options for Integrations
You can use push options to skip integration CI/CD pipelines.
| Push option | Description | Example |
|--------------------------------|-------------|---------|
| `integrations.skip_ci` | Skip push events for CI/CD integrations, such as Atlassian Bamboo, Buildkite, Drone, Jenkins, and JetBrains TeamCity. Introduced in [GitLab 16.2](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/123837). | `git push -o integrations.skip_ci` |
### Push options for merge requests

2
doc/update/background_migrations_troubleshooting.md
View File

@ -28,7 +28,7 @@ Expected batched background migration for the given configuration to be marked a
}
```
First, check if you have followed the [version-specific upgrade instructions for 14.2](../update/versions/gitlab_14_changes.md#1420).
First, check if you have followed the [version-specific upgrade instructions for 14.2](https://docs.gitlab.com/17.3/ee/update/versions/gitlab_14_changes.html#1420).
If you have, you can [manually finish the batched background migration](background_migrations.md#finish-a-failed-migration-manually)).
If you haven't, choose one of the following methods:

959
doc/update/versions/gitlab_14_changes.md
View File

@ -1,956 +1,11 @@
---
stage: Systems
group: Distribution
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
redirect_to: '../index.md'
remove_date: '2024-12-11'
---
<!-- vale gitlab_base.OutdatedVersions = NO -->
<!--- start_remove The following content will be removed on remove_date: '2024-08-30' -->
This document was moved to [another location](../index.md).
# GitLab 14 changes
DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** Self-managed
This page contains upgrade information for minor and patch versions of GitLab 14.
Ensure you review these instructions for:
- Your installation type.
- All versions between your current version and your target version.
For more information about upgrading GitLab Helm Chart, see [the release notes for 5.0](https://docs.gitlab.com/charts/releases/5_0.html).
## 14.10.0
- Before upgrading to GitLab 14.10, you must already have the latest 14.9.Z installed on your instance.
The upgrade to GitLab 14.10 executes a [concurrent index drop](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/84308) of unneeded
entries from the `ci_job_artifacts` database table. This could potentially run for multiple minutes, especially if the table has a lot of
traffic and the migration is unable to acquire a lock. It is advised to let this process finish as restarting may result in data loss.
- If you run GitLab with external PostgreSQL, particularly AWS RDS, ensure you
upgrade PostgreSQL to patch levels to a minimum of 12.7 or 13.3 before
upgrading to GitLab 14.8 or later.
[In 14.8](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/75511)
for GitLab Enterprise Edition and [in 15.0](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/87983)
for GitLab Community Edition a GitLab feature called Loose Foreign Keys was enabled.
After it was enabled, we have had reports of unplanned PostgreSQL restarts caused
by a database engine bug that causes a segmentation fault.
For more information, see [issue 364763](https://gitlab.com/gitlab-org/gitlab/-/issues/364763).
- Upgrading to patch level 14.10.3 or later might encounter a one-hour timeout due to a long running database data change,
if it was not completed while running GitLab 14.9.
```plaintext
FATAL: Mixlib::ShellOut::CommandTimeout: rails_migration[gitlab-rails]
(gitlab::database_migrations line 51) had an error:
[..]
Mixlib::ShellOut::CommandTimeout: Command timed out after 3600s:
```
A workaround exists to [complete the data change and the upgrade manually](../package/package_troubleshooting.md#mixlibshelloutcommandtimeout-rails_migrationgitlab-rails--command-timed-out-after-3600s).
### Linux package installations
- In GitLab 14.10, Gitaly has introduced a new runtime directory. This directory is intended to hold all files and
directories Gitaly needs to create at runtime to operate correctly. This includes, for example, internal sockets, the
Git execution environment, or the temporary hooks directory.
This new configuration can be set via `gitaly['runtime_dir']`. It replaces the old `gitaly['internal_socket_dir']`
configuration. If the internal socket directory is not explicitly configured, sockets will be created in the runtime directory.
Support for `gitaly['internal_socket_dir']` will be removed in 15.0.
## 14.9.0
- Database changes made by the upgrade to GitLab 14.9 can take hours or days to complete on larger GitLab instances.
These [batched background migrations](../background_migrations.md#batched-background-migrations) update whole database tables to ensure corresponding
records in `namespaces` table for each record in `projects` table.
After you upgrade to 14.9.0 or a later 14.9 patch version,
[batched background migrations must finish](../background_migrations.md#batched-background-migrations)
before you upgrade to a later version.
If the migrations are not finished and you try to upgrade to a later version,
you see errors like:
```plaintext
Expected batched background migration for the given configuration to be marked as 'finished', but it is 'active':
```
Or
```plaintext
Error executing action `run` on resource 'bash[migrate gitlab-rails database]'
================================================================================
Mixlib::ShellOut::ShellCommandFailed
------------------------------------
Command execution failed. STDOUT/STDERR suppressed for sensitive resource
```
- GitLab 14.9.0 includes a
[background migration `ResetDuplicateCiRunnersTokenValuesOnProjects`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/79140)
that may remain stuck permanently in a **pending** state.
To clean up this stuck job, run the following in the [GitLab Rails Console](../../administration/operations/rails_console.md):
```ruby
Gitlab::Database::BackgroundMigrationJob.pending.where(class_name: "ResetDuplicateCiRunnersTokenValuesOnProjects").find_each do |job|
puts Gitlab::Database::BackgroundMigrationJob.mark_all_as_succeeded("ResetDuplicateCiRunnersTokenValuesOnProjects", job.arguments)
end
```
- If you run GitLab with external PostgreSQL, particularly AWS RDS, ensure you
upgrade PostgreSQL to patch levels to a minimum of 12.7 or 13.3 before
upgrading to GitLab 14.8 or later.
[In 14.8](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/75511)
for GitLab Enterprise Edition and [in 15.0](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/87983)
for GitLab Community Edition a GitLab feature called Loose Foreign Keys was enabled.
After it was enabled, we have had reports of unplanned PostgreSQL restarts caused
by a database engine bug that causes a segmentation fault.
For more information, see [issue 364763](https://gitlab.com/gitlab-org/gitlab/-/issues/364763).
### Geo installations
DETAILS:
**Tier:** Premium, Ultimate
**Offering:** Self-managed
- **Do not** upgrade to GitLab 14.9.0. Instead, use 14.9.1 or later.
We've discovered an issue with Geo's CI verification feature that may
[cause job traces to be lost](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/6664). This issue was fixed
in [the GitLab 14.9.1 patch release](https://about.gitlab.com/releases/2022/03/23/gitlab-14-9-1-released/).
If you have already upgraded to GitLab 14.9.0, you can disable the feature causing the issue by
[disabling the `geo_job_artifact_replication` feature flag](../../administration/feature_flags.md#how-to-enable-and-disable-features-behind-flags).
## 14.8.0
- If upgrading from a version earlier than 14.6.5, 14.7.4, or 14.8.2, review the [Critical Security Release: 14.8.2, 14.7.4, and 14.6.5](https://about.gitlab.com/releases/2022/02/25/critical-security-release-gitlab-14-8-2-released/) blog post.
Updating to 14.8.2 or later resets runner registration tokens for your groups and projects.
- The agent server for Kubernetes [is enabled by default](https://about.gitlab.com/releases/2022/02/22/gitlab-14-8-released/#the-agent-server-for-kubernetes-is-enabled-by-default)
on Omnibus installations. If you run GitLab at scale,
such as [the reference architectures](../../administration/reference_architectures/index.md),
you must disable the agent on the following server types, **if the agent is not required**.
- Praefect
- Gitaly
- Sidekiq
- Redis (if configured using `redis['enable'] = true` and not via `roles`)
- Container registry
- Any other server types based on `roles(['application_role'])`, such as the GitLab Rails nodes
[The reference architectures](../../administration/reference_architectures/index.md) have been updated
with this configuration change and a specific role for standalone Redis servers.
Steps to disable the agent:
1. Add `gitlab_kas['enable'] = false` to `gitlab.rb`.
1. If the server is already upgraded to 14.8, run `gitlab-ctl reconfigure`.
- GitLab 14.8.0 includes a
[background migration `PopulateTopicsNonPrivateProjectsCount`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/79140)
that may remain stuck permanently in a **pending** state.
To clean up this stuck job, run the following in the [GitLab Rails Console](../../administration/operations/rails_console.md):
```ruby
Gitlab::Database::BackgroundMigrationJob.pending.where(class_name: "PopulateTopicsNonPrivateProjectsCount").find_each do |job|
puts Gitlab::Database::BackgroundMigrationJob.mark_all_as_succeeded("PopulateTopicsNonPrivateProjectsCount", job.arguments)
end
```
- If upgrading from a version earlier than 14.3.0, to avoid
[an issue with job retries](https://gitlab.com/gitlab-org/gitlab/-/issues/357822), first upgrade
to GitLab 14.7.x and make sure all batched migrations have finished.
- If upgrading from version 14.3.0 or later, you might notice a failed
[batched migration](../background_migrations.md#batched-background-migrations) named
`BackfillNamespaceIdForNamespaceRoute`. You can [ignore](https://gitlab.com/gitlab-org/gitlab/-/issues/357822)
this. Retry it after you upgrade to version 14.9.x.
- If you run GitLab with external PostgreSQL, particularly AWS RDS, ensure you
upgrade PostgreSQL to patch levels to a minimum of 12.7 or 13.3 before
upgrading to GitLab 14.8 or later.
[In 14.8](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/75511)
for GitLab Enterprise Edition and [in 15.0](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/87983)
for GitLab Community Edition a GitLab feature called Loose Foreign Keys was enabled.
After it was enabled, we have had reports of unplanned PostgreSQL restarts caused
by a database engine bug that causes a segmentation fault.
For more information, see [issue 364763](https://gitlab.com/gitlab-org/gitlab/-/issues/364763).
## 14.7.0
- If upgrading from a version earlier than 14.6.5, 14.7.4, or 14.8.2, review the [Critical Security Release: 14.8.2, 14.7.4, and 14.6.5](https://about.gitlab.com/releases/2022/02/25/critical-security-release-gitlab-14-8-2-released/) blog post.
Updating to 14.7.4 or later resets runner registration tokens for your groups and projects.
- GitLab 14.7 introduced a change where Gitaly expects persistent files in the `/tmp` directory.
When using the `noatime` mount option on `/tmp` in a node running Gitaly, most Linux distributions
run into [an issue with Git server hooks getting deleted](https://gitlab.com/gitlab-org/gitaly/-/issues/4113).
These conditions are present in the default Amazon Linux configuration.
If your Linux distribution manages files in `/tmp` with the `tmpfiles.d` service, you
can override the behavior of `tmpfiles.d` for the Gitaly files and avoid this issue:
```shell
sudo printf "x /tmp/gitaly-%s-*\n" hooks git-exec-path >/etc/tmpfiles.d/gitaly-workaround.conf
```
This issue is fixed in GitLab 14.10 and later when using the [Gitaly runtime directory](https://docs.gitlab.com/omnibus/update/gitlab_14_changes.html#gitaly-runtime-directory)
to specify a location to store persistent files.
### Linux package installations
- In GitLab 14.8, we are upgrading Redis from 6.0.16 to 6.2.6. This upgrade is expected to be fully backwards compatible.
Follow [the zero-downtime instructions](../zero_downtime.md) for upgrading your Redis HA cluster.
### Geo installations
DETAILS:
**Tier:** Premium, Ultimate
**Offering:** Self-managed
- LFS objects import and mirror issue in GitLab 14.6.0 to 14.7.2.
When Geo is enabled, LFS objects fail to be saved for imported or mirrored projects.
[This bug](https://gitlab.com/gitlab-org/gitlab/-/issues/352368) was fixed in GitLab 14.8.0 and backported into 14.7.3.
- There is [an issue in GitLab 14.2 through 14.7](https://gitlab.com/gitlab-org/gitlab/-/issues/299819#note_822629467)
that affects Geo when the GitLab-managed object storage replication is used, causing blob object types to fail synchronization.
Since GitLab 14.2, verification failures result in synchronization failures and cause a resynchronization of these objects.
As verification is not yet implemented for files stored in object storage (see
[issue 13845](https://gitlab.com/gitlab-org/gitlab/-/issues/13845) for more details), this
results in a loop that consistently fails for all objects stored in object storage.
For information on how to fix this, see
[Troubleshooting - Failed syncs with GitLab-managed object storage replication](https://archives.docs.gitlab.com/14.10/ee/administration/geo/replication/troubleshooting#failed-syncs-with-gitlab-managed-object-storage-replication).
## 14.6.0
- If upgrading from a version earlier than 14.6.5, 14.7.4, or 14.8.2, review the [Critical Security Release: 14.8.2, 14.7.4, and 14.6.5](https://about.gitlab.com/releases/2022/02/25/critical-security-release-gitlab-14-8-2-released/) blog post.
Updating to 14.6.5 or later resets runner registration tokens for your groups and projects.
### Geo installations
DETAILS:
**Tier:** Premium, Ultimate
**Offering:** Self-managed
- LFS objects import and mirror issue in GitLab 14.6.0 to 14.7.2.
When Geo is enabled, LFS objects fail to be saved for imported or mirrored projects.
[This bug](https://gitlab.com/gitlab-org/gitlab/-/issues/352368) was fixed in GitLab 14.8.0 and backported into 14.7.3.
- There is [an issue in GitLab 14.2 through 14.7](https://gitlab.com/gitlab-org/gitlab/-/issues/299819#note_822629467)
that affects Geo when the GitLab-managed object storage replication is used, causing blob object types to fail synchronization.
Since GitLab 14.2, verification failures result in synchronization failures and cause a resynchronization of these objects.
As verification is not yet implemented for files stored in object storage (see
[issue 13845](https://gitlab.com/gitlab-org/gitlab/-/issues/13845) for more details), this
results in a loop that consistently fails for all objects stored in object storage.
For information on how to fix this, see
[Troubleshooting - Failed syncs with GitLab-managed object storage replication](https://archives.docs.gitlab.com/14.10/ee/administration/geo/replication/troubleshooting#failed-syncs-with-gitlab-managed-object-storage-replication).
## 14.5.0
- Connections between Workhorse and Gitaly use the Gitaly `backchannel` protocol by default. If you deployed a gRPC proxy between Workhorse and Gitaly,
Workhorse can no longer connect. As a workaround, [disable the temporary `workhorse_use_sidechannel`](../../administration/feature_flags.md#enable-or-disable-the-feature)
feature flag. If you need a proxy between Workhorse and Gitaly, use a TCP proxy. If you have feedback about this change, go to [this issue](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/1301).
- In 14.1 we introduced a background migration that changes how we store merge request diff commits,
to significantly reduce the amount of storage needed.
In 14.5 we introduce a set of migrations that wrap up this process by making sure
that all remaining jobs over the `merge_request_diff_commits` table are completed.
These jobs have already been processed in most cases so that no extra time is necessary during an upgrade to 14.5.
However, if there are remaining jobs or you haven't already upgraded to 14.1,
the deployment may take multiple hours to complete.
All merge request diff commits automatically incorporate these changes, and there are no
additional requirements to perform the upgrade.
Existing data in the `merge_request_diff_commits` table remains unpacked until you run `VACUUM FULL merge_request_diff_commits`.
However, the `VACUUM FULL` operation locks and rewrites the entire `merge_request_diff_commits` table,
so the operation takes some time to complete and it blocks access to this table until the end of the process.
We advise you to only run this command while GitLab is not actively used or it is taken offline for the duration of the process.
The time it takes to complete depends on the size of the table, which can be obtained by using `select pg_size_pretty(pg_total_relation_size('merge_request_diff_commits'));`.
For more information, refer to [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/331823).
- GitLab 14.5.0 includes a
[background migration `UpdateVulnerabilityOccurrencesLocation`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/72788)
that may remain stuck permanently in a **pending** state when the instance lacks records that match the migration's target.
To clean up this stuck job, run the following in the [GitLab Rails Console](../../administration/operations/rails_console.md):
```ruby
Gitlab::Database::BackgroundMigrationJob.pending.where(class_name: "UpdateVulnerabilityOccurrencesLocation").find_each do |job|
puts Gitlab::Database::BackgroundMigrationJob.mark_all_as_succeeded("UpdateVulnerabilityOccurrencesLocation", job.arguments)
end
```
- Upgrading to 14.5 (or later) [might encounter a one hour timeout](https://gitlab.com/gitlab-org/gitlab/-/issues/354211)
owing to a long running database data change.
```plaintext
FATAL: Mixlib::ShellOut::CommandTimeout: rails_migration[gitlab-rails]
(gitlab::database_migrations line 51) had an error:
[..]
Mixlib::ShellOut::CommandTimeout: Command timed out after 3600s:
```
[There is a workaround to complete the data change and the upgrade manually](../package/package_troubleshooting.md#mixlibshelloutcommandtimeout-rails_migrationgitlab-rails--command-timed-out-after-3600s)
- As part of [enabling real-time issue assignees](https://gitlab.com/gitlab-org/gitlab/-/issues/330117), Action Cable is now enabled by default.
For **self-compiled (source) installations**, `config/cable.yml` is required to be present.
Configure this by running:
```shell
cd /home/git/gitlab
sudo -u git -H cp config/cable.yml.example config/cable.yml
# Change the Redis socket path if you are not using the default Debian / Ubuntu configuration
sudo -u git -H editor config/cable.yml
```
### Self-compiled installations
- When `make` is run, Gitaly builds are now created in `_build/bin` and no longer in the root directory of the source directory. If you
are using a self-compiled installation, update paths to these binaries in your [systemd unit files](../upgrading_from_source.md#configure-systemd-units)
or [init scripts](../upgrading_from_source.md#configure-sysv-init-script) by [following the documentation](../upgrading_from_source.md).
### Geo installations
DETAILS:
**Tier:** Premium, Ultimate
**Offering:** Self-managed
- There is [an issue in GitLab 14.2 through 14.7](https://gitlab.com/gitlab-org/gitlab/-/issues/299819#note_822629467)
that affects Geo when the GitLab-managed object storage replication is used, causing blob object types to fail synchronization.
Since GitLab 14.2, verification failures result in synchronization failures and cause a resynchronization of these objects.
As verification is not yet implemented for files stored in object storage (see
[issue 13845](https://gitlab.com/gitlab-org/gitlab/-/issues/13845) for more details), this
results in a loop that consistently fails for all objects stored in object storage.
For information on how to fix this, see
[Troubleshooting - Failed syncs with GitLab-managed object storage replication](https://archives.docs.gitlab.com/14.10/ee/administration/geo/replication/troubleshooting#failed-syncs-with-gitlab-managed-object-storage-replication).
## 14.4.4
- For [zero-downtime upgrades](../zero_downtime.md) on a GitLab cluster with separate Web and API nodes, you must enable the `paginated_tree_graphql_query` [feature flag](../../administration/feature_flags.md#enable-or-disable-the-feature) _before_ upgrading GitLab Web nodes to 14.4.
This is because we [enabled `paginated_tree_graphql_query` by default in 14.4](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/70913/diffs), so if GitLab UI is on 14.4 and its API is on 14.3, the frontend has this feature enabled but the backend has it disabled. This results in the following error:
```shell
bundle.esm.js:63 Uncaught (in promise) Error: GraphQL error: Field 'paginatedTree' doesn't exist on type 'Repository'
```
## 14.4.1 and 14.4.2
### Geo installations
DETAILS:
**Tier:** Premium, Ultimate
**Offering:** Self-managed
- There is [an issue in GitLab 14.4.0 through 14.4.2](#1440) that can affect
Geo and other features that rely on cronjobs. We recommend upgrading to GitLab 14.4.3 or later.
## 14.4.0
- Git 2.33.x and later is required. We recommend you use the
[Git version provided by Gitaly](../../install/installation.md#git).
- When [Maintenance mode](../../administration/maintenance_mode/index.md) is
enabled, users cannot sign in with SSO, SAML, or LDAP.
Users who were signed in before Maintenance mode was enabled, continue to be
signed in. If the administrator who enabled Maintenance mode loses their
session, then they can't disable Maintenance mode via the UI. In that case,
you can
[disable Maintenance mode via the API or Rails console](../../administration/maintenance_mode/index.md#disable-maintenance-mode).
[This bug](https://gitlab.com/gitlab-org/gitlab/-/issues/329261) was fixed in
GitLab 14.5.0 and backported into 14.4.3 and 14.3.5.
- After enabling database load balancing by default in 14.4.0, we found an issue where
[cron jobs would not work if the connection to PostgreSQL was severed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/73716),
as Sidekiq would continue using a bad connection. Geo and other features that rely on
cron jobs running regularly do not work until Sidekiq is restarted. We recommend
upgrading to GitLab 14.4.3 and later if this issue affects you.
- After enabling database load balancing by default in 14.4.0, we found an issue where
[Database load balancing does not work with an AWS Aurora cluster](https://gitlab.com/gitlab-org/gitlab/-/issues/220617).
We recommend moving your databases from Aurora to RDS for PostgreSQL before
upgrading. Refer to [Moving GitLab databases to a different PostgreSQL instance](../../administration/postgresql/moving.md).
- GitLab 14.4.0 includes a
[background migration `PopulateTopicsTotalProjectsCountCache`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/71033)
that may remain stuck permanently in a **pending** state when the instance lacks records that match the migration's target.
To clean up this stuck job, run the following in the [GitLab Rails Console](../../administration/operations/rails_console.md):
```ruby
Gitlab::Database::BackgroundMigrationJob.pending.where(class_name: "PopulateTopicsTotalProjectsCountCache").find_each do |job|
puts Gitlab::Database::BackgroundMigrationJob.mark_all_as_succeeded("PopulateTopicsTotalProjectsCountCache", job.arguments)
end
```
### Linux package installations
- In GitLab 14.4, the provided Grafana version is 7.5, this is a downgrade from the Grafana 8.1 version introduced in
GitLab 14.3. This was reverted to an Apache-licensed Grafana release to allow time to consider the implications of the
newer AGPL-licensed releases.
Users that have customized their Grafana install with plugins or library panels may experience errors in Grafana after
the downgrade. If the errors persist after a Grafana restart you may need to reset the Grafana db and re-add the
customizations. The Grafana database can be reset with `sudo gitlab-ctl reset-grafana`.
### Geo installations
DETAILS:
**Tier:** Premium, Ultimate
**Offering:** Self-managed
- There is [an issue in GitLab 14.2 through 14.7](https://gitlab.com/gitlab-org/gitlab/-/issues/299819#note_822629467)
that affects Geo when the GitLab-managed object storage replication is used, causing blob object types to fail synchronization.
Since GitLab 14.2, verification failures result in synchronization failures and cause a resynchronization of these objects.
As verification is not yet implemented for files stored in object storage (see
[issue 13845](https://gitlab.com/gitlab-org/gitlab/-/issues/13845) for more details), this
results in a loop that consistently fails for all objects stored in object storage.
For information on how to fix this, see
[Troubleshooting - Failed syncs with GitLab-managed object storage replication](https://archives.docs.gitlab.com/14.10/ee/administration/geo/replication/troubleshooting#failed-syncs-with-gitlab-managed-object-storage-replication).
- There is [an issue in GitLab 14.4.0 through 14.4.2](#1440) that can affect
Geo and other features that rely on cronjobs. We recommend upgrading to GitLab 14.4.3 or later.
## 14.3.0
- [Instances running 14.0.0 - 14.0.4 should not upgrade directly to GitLab 14.2 or later](#upgrading-to-later-14y-releases).
- Ensure [batched background migrations finish](../background_migrations.md#batched-background-migrations) before upgrading
to 14.3.Z from earlier GitLab 14 releases.
- GitLab 14.3.0 contains post-deployment migrations to [address Primary Key overflow risk for tables with an integer PK](https://gitlab.com/groups/gitlab-org/-/epics/4785) for the tables listed below:
- [`ci_builds.id`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/70245)
- [`ci_builds.stage_id`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/66688)
- [`ci_builds_metadata`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/65692)
- [`taggings`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/66625)
- [`events`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/64779)
If the migrations are executed as part of a no-downtime deployment, there's a risk of failure due to lock conflicts with the application logic, resulting in lock timeout or deadlocks. In each case, these migrations are safe to re-run until successful:
```shell
# For Omnibus GitLab
sudo gitlab-rake db:migrate
# For source installations
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
```
- After upgrading to 14.3, ensure that all the `MigrateMergeRequestDiffCommitUsers` background
migration jobs have completed before continuing with upgrading to GitLab 14.5 or later.
This is especially important if your GitLab instance has a large
`merge_request_diff_commits` table. Any pending
`MigrateMergeRequestDiffCommitUsers` background migration jobs are
foregrounded in GitLab 14.5, and may take a long time to complete.
You can check the count of pending jobs for
`MigrateMergeRequestDiffCommitUsers` by using the PostgreSQL console (or `sudo gitlab-psql`):
```sql
select status, count(*) from background_migration_jobs
where class_name = 'MigrateMergeRequestDiffCommitUsers' group by status;
```
As jobs are completed, the database records change from `0` (pending) to `1`. If the number of
pending jobs doesn't decrease after a while, it's possible that the
`MigrateMergeRequestDiffCommitUsers` background migration jobs have failed. You
can check for errors in the Sidekiq logs:
```shell
sudo grep MigrateMergeRequestDiffCommitUsers /var/log/gitlab/sidekiq/current | grep -i error
```
If needed, you can attempt to run the `MigrateMergeRequestDiffCommitUsers` background
migration jobs manually in the [GitLab Rails Console](../../administration/operations/rails_console.md).
This can be done using Sidekiq asynchronously, or by using a Rails process directly:
- Using Sidekiq to schedule jobs asynchronously:
```ruby
# For the first run, only attempt to execute 1 migration. If successful, increase
# the limit for subsequent runs
limit = 1
jobs = Gitlab::Database::BackgroundMigrationJob.for_migration_class('MigrateMergeRequestDiffCommitUsers').pending.to_a
pp "#{jobs.length} jobs remaining"
jobs.first(limit).each do |job|
BackgroundMigrationWorker.perform_in(5.minutes, 'MigrateMergeRequestDiffCommitUsers', job.arguments)
end
```
NOTE:
The queued jobs can be monitored using the Sidekiq admin panel, which can be accessed at the `/admin/sidekiq` endpoint URI.
- Using a Rails process to run jobs synchronously:
```ruby
def process(concurrency: 1)
queue = Queue.new
Gitlab::Database::BackgroundMigrationJob
.where(class_name: 'MigrateMergeRequestDiffCommitUsers', status: 0)
.each { |job| queue << job }
concurrency
.times
.map do
Thread.new do
Thread.abort_on_exception = true
loop do
job = queue.pop(true)
time = Benchmark.measure do
Gitlab::BackgroundMigration::MigrateMergeRequestDiffCommitUsers
.new
.perform(*job.arguments)
end
puts "#{job.id} finished in #{time.real.round(2)} seconds"
rescue ThreadError
break
end
end
end
.each(&:join)
end
ActiveRecord::Base.logger.level = Logger::ERROR
process
```
NOTE:
When using Rails to execute these background migrations synchronously, make sure that the machine running the process has sufficient resources to handle the task. If the process gets terminated, it's likely due to insufficient memory available. If your SSH session times out after a while, it might be necessary to run the previous code by using a terminal multiplexer like `screen` or `tmux`.
- When [Maintenance mode](../../administration/maintenance_mode/index.md) is
enabled, users cannot sign in with SSO, SAML, or LDAP.
Users who were signed in before Maintenance mode was enabled, continue to be
signed in. If the administrator who enabled Maintenance mode loses their
session, then they can't disable Maintenance mode via the UI. In that case,
you can
[disable Maintenance mode via the API or Rails console](../../administration/maintenance_mode/index.md#disable-maintenance-mode).
[This bug](https://gitlab.com/gitlab-org/gitlab/-/issues/329261) was fixed in
GitLab 14.5.0 and backported into 14.4.3 and 14.3.5.
- You may see the following error when setting up two factor authentication (2FA) for accounts
that authenticate using an LDAP password:
```plaintext
You must provide a valid current password
```
- The error occurs because verification is incorrectly performed against accounts'
randomly generated internal GitLab passwords, not the LDAP passwords.
- This is [fixed in GitLab 14.5.0 and backported to 14.4.3](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/73538).
- Workarounds:
- Instead of upgrading to GitLab 14.3.x to comply with the supported upgrade path:
1. Upgrade to 14.4.5.
1. Make sure the [`MigrateMergeRequestDiffCommitUsers` background migration](#1430) has finished.
1. Upgrade to GitLab 14.5 or later.
- Reset the random password for affected accounts, using [the Rake task](../../security/reset_user_password.md#use-a-rake-task):
```plaintext
sudo gitlab-rake "gitlab:password:reset[user_handle]"
```
- If you encounter the error, `I18n::InvalidLocale: :en is not a valid locale`, when starting the application, follow the [patching](https://handbook.gitlab.com/handbook/support/workflows/patching_an_instance/) process. Use [122978](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/122978) as the `mr_iid`.
### Self-compiled installations
- Ruby 2.7.4 is required. Refer to [the Ruby installation instructions](../../install/installation.md#2-ruby)
for how to proceed.
### Geo installations
DETAILS:
**Tier:** Premium, Ultimate
**Offering:** Self-managed
- There is [an issue in GitLab 14.2 through 14.7](https://gitlab.com/gitlab-org/gitlab/-/issues/299819#note_822629467)
that affects Geo when the GitLab-managed object storage replication is used, causing blob object types to fail synchronization.
Since GitLab 14.2, verification failures result in synchronization failures and cause a resynchronization of these objects.
As verification is not yet implemented for files stored in object storage (see
[issue 13845](https://gitlab.com/gitlab-org/gitlab/-/issues/13845) for more details), this
results in a loop that consistently fails for all objects stored in object storage.
For information on how to fix this, see
[Troubleshooting - Failed syncs with GitLab-managed object storage replication](https://archives.docs.gitlab.com/14.10/ee/administration/geo/replication/troubleshooting#failed-syncs-with-gitlab-managed-object-storage-replication).
- We found an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/336013) where the container registry replication
wasn't fully working if you used multi-arch images. In case of a multi-arch image, only the primary architecture
(for example `amd64`) would be replicated to the secondary site. This has been [fixed in GitLab 14.3](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67624) and was backported to 14.2 and 14.1, but manual steps are required to force a re-sync.
You can check if you are affected by running:
```shell
docker manifest inspect <SECONDARY_IMAGE_LOCATION> | jq '.mediaType'
```
Where `<SECONDARY_IMAGE_LOCATION>` is a container image on your secondary site.
If the output matches `application/vnd.docker.distribution.manifest.list.v2+json`
(there can be a `mediaType` entry at several levels, we only care about the top level entry),
then you don't need to do anything.
Otherwise, for each **secondary** site, on a Rails application node, open a [Rails console](../../administration/operations/rails_console.md), and run the following:
```ruby
list_type = 'application/vnd.docker.distribution.manifest.list.v2+json'
Geo::ContainerRepositoryRegistry.synced.each do |gcr|
cr = gcr.container_repository
primary = Geo::ContainerRepositorySync.new(cr)
cr.tags.each do |tag|
primary_manifest = JSON.parse(primary.send(:client).repository_raw_manifest(cr.path, tag.name))
next unless primary_manifest['mediaType'].eql?(list_type)
cr.delete_tag_by_name(tag.name)
end
primary.execute
end
```
If you are running a version prior to 14.1 and are using Geo and multi-arch containers in your container registry,
we recommend [upgrading](../../administration/geo/replication/upgrading_the_geo_sites.md) to at least GitLab 14.1.
## 14.2.0
- [Instances running 14.0.0 - 14.0.4 should not upgrade directly to GitLab 14.2 or later](#upgrading-to-later-14y-releases).
- Ensure [batched background migrations finish](../background_migrations.md#batched-background-migrations) before upgrading
to 14.2.Z from earlier GitLab 14 releases.
- GitLab 14.2.0 contains background migrations to [address Primary Key overflow risk for tables with an integer PK](https://gitlab.com/groups/gitlab-org/-/epics/4785) for the tables listed below:
- [`ci_build_needs`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/65216)
- [`ci_build_trace_chunks`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/66123)
- [`ci_builds_runner_session`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/66433)
- [`deployments`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67341)
- [`geo_job_artifact_deleted_events`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/66763)
- [`push_event_payloads`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67299)
- `ci_job_artifacts`:
- [Finalize `job_id` conversion to `bigint` for `ci_job_artifacts`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67774)
- [Finalize `ci_job_artifacts` conversion to `bigint`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/65601)
If the migrations are executed as part of a no-downtime deployment, there's a risk of failure due to lock conflicts with the application logic, resulting in lock timeout or deadlocks. In each case, these migrations are safe to re-run until successful:
```shell
# For Omnibus GitLab
sudo gitlab-rake db:migrate
# For source installations
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
```
- When [Maintenance mode](../../administration/maintenance_mode/index.md) is
enabled, users cannot sign in with SSO, SAML, or LDAP.
Users who were signed in before Maintenance mode was enabled, continue to be
signed in. If the administrator who enabled Maintenance mode loses their
session, then they can't disable Maintenance mode via the UI. In that case,
you can
[disable Maintenance mode via the API or Rails console](../../administration/maintenance_mode/index.md#disable-maintenance-mode).
[This bug](https://gitlab.com/gitlab-org/gitlab/-/issues/329261) was fixed in
GitLab 14.5.0 and backported into 14.4.3 and 14.3.5.
- GitLab 14.2.0 includes a
[background migration `BackfillDraftStatusOnMergeRequests`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67687)
that may remain stuck permanently in a **pending** state when the instance lacks records that match the migration's target.
To clean up this stuck job, run the following in the [GitLab Rails Console](../../administration/operations/rails_console.md):
```ruby
Gitlab::Database::BackgroundMigrationJob.pending.where(class_name: "BackfillDraftStatusOnMergeRequests").find_each do |job|
puts Gitlab::Database::BackgroundMigrationJob.mark_all_as_succeeded("BackfillDraftStatusOnMergeRequests", job.arguments)
end
```
- If you encounter the error, `I18n::InvalidLocale: :en is not a valid locale`, when starting the application, follow the [patching](https://handbook.gitlab.com/handbook/support/workflows/patching_an_instance/) process. Use [123476](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/123476) as the `mr_iid`.
### Geo installations
DETAILS:
**Tier:** Premium, Ultimate
**Offering:** Self-managed
- There is [an issue in GitLab 14.2 through 14.7](https://gitlab.com/gitlab-org/gitlab/-/issues/299819#note_822629467)
that affects Geo when the GitLab-managed object storage replication is used, causing blob object types to fail synchronization.
Since GitLab 14.2, verification failures result in synchronization failures and cause a resynchronization of these objects.
As verification is not yet implemented for files stored in object storage (see
[issue 13845](https://gitlab.com/gitlab-org/gitlab/-/issues/13845) for more details), this
results in a loop that consistently fails for all objects stored in object storage.
For information on how to fix this, see
[Troubleshooting - Failed syncs with GitLab-managed object storage replication](https://archives.docs.gitlab.com/14.10/ee/administration/geo/replication/troubleshooting#failed-syncs-with-gitlab-managed-object-storage-replication).
- We found an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/336013) where the container registry replication
wasn't fully working if you used multi-arch images. In case of a multi-arch image, only the primary architecture
(for example `amd64`) would be replicated to the secondary site. This has been [fixed in GitLab 14.3](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67624) and was backported to 14.2 and 14.1, but manual steps are required to force a re-sync.
You can check if you are affected by running:
```shell
docker manifest inspect <SECONDARY_IMAGE_LOCATION> | jq '.mediaType'
```
Where `<SECONDARY_IMAGE_LOCATION>` is a container image on your secondary site.
If the output matches `application/vnd.docker.distribution.manifest.list.v2+json`
(there can be a `mediaType` entry at several levels, we only care about the top level entry),
then you don't need to do anything.
Otherwise, for each **secondary** site, on a Rails application node, open a [Rails console](../../administration/operations/rails_console.md), and run the following:
```ruby
list_type = 'application/vnd.docker.distribution.manifest.list.v2+json'
Geo::ContainerRepositoryRegistry.synced.each do |gcr|
cr = gcr.container_repository
primary = Geo::ContainerRepositorySync.new(cr)
cr.tags.each do |tag|
primary_manifest = JSON.parse(primary.send(:client).repository_raw_manifest(cr.path, tag.name))
next unless primary_manifest['mediaType'].eql?(list_type)
cr.delete_tag_by_name(tag.name)
end
primary.execute
end
```
If you are running a version prior to 14.1 and are using Geo and multi-arch containers in your container registry,
we recommend [upgrading](../../administration/geo/replication/upgrading_the_geo_sites.md) to at least GitLab 14.1.
## 14.1.0
- [Instances running 14.0.0 - 14.0.4 should not upgrade directly to GitLab 14.2 or later](#upgrading-to-later-14y-releases)
but can upgrade to 14.1.Z.
It is not required for instances already running 14.0.5 (or later) to stop at 14.1.Z.
14.1 is included on the upgrade path for the broadest compatibility
with self-managed installations, and ensure 14.0.0-14.0.4 installations do not
encounter issues with [batched background migrations](../background_migrations.md#batched-background-migrations).
- Upgrading to GitLab [14.5](#1450) (or later) may take a lot longer if you do not upgrade to at least 14.1
first. The 14.1 merge request diff commits database migration can take hours to run, but runs in the
background while GitLab is in use. GitLab instances upgraded directly from 14.0 to 14.5 or later must
run the migration in the foreground and therefore take a lot longer to complete.
- When [Maintenance mode](../../administration/maintenance_mode/index.md) is
enabled, users cannot sign in with SSO, SAML, or LDAP.
Users who were signed in before Maintenance mode was enabled, continue to be
signed in. If the administrator who enabled Maintenance mode loses their
session, then they can't disable Maintenance mode via the UI. In that case,
you can
[disable Maintenance mode via the API or Rails console](../../administration/maintenance_mode/index.md#disable-maintenance-mode).
[This bug](https://gitlab.com/gitlab-org/gitlab/-/issues/329261) was fixed in
GitLab 14.5.0 and backported into 14.4.3 and 14.3.5.
- If you encounter the error, `I18n::InvalidLocale: :en is not a valid locale`, when starting the application, follow the [patching](https://handbook.gitlab.com/handbook/support/workflows/patching_an_instance/) process. Use [123475](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/123475) as the `mr_iid`.
### Geo installations
DETAILS:
**Tier:** Premium, Ultimate
**Offering:** Self-managed
- We found an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/336013) where the container registry replication
wasn't fully working if you used multi-arch images. In case of a multi-arch image, only the primary architecture
(for example `amd64`) would be replicated to the secondary site. This has been [fixed in GitLab 14.3](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67624) and was backported to 14.2 and 14.1, but manual steps are required to force a re-sync.
You can check if you are affected by running:
```shell
docker manifest inspect <SECONDARY_IMAGE_LOCATION> | jq '.mediaType'
```
Where `<SECONDARY_IMAGE_LOCATION>` is a container image on your secondary site.
If the output matches `application/vnd.docker.distribution.manifest.list.v2+json`
(there can be a `mediaType` entry at several levels, we only care about the top level entry),
then you don't need to do anything.
Otherwise, for each **secondary** site, on a Rails application node, open a [Rails console](../../administration/operations/rails_console.md), and run the following:
```ruby
list_type = 'application/vnd.docker.distribution.manifest.list.v2+json'
Geo::ContainerRepositoryRegistry.synced.each do |gcr|
cr = gcr.container_repository
primary = Geo::ContainerRepositorySync.new(cr)
cr.tags.each do |tag|
primary_manifest = JSON.parse(primary.send(:client).repository_raw_manifest(cr.path, tag.name))
next unless primary_manifest['mediaType'].eql?(list_type)
cr.delete_tag_by_name(tag.name)
end
primary.execute
end
```
If you are running a version prior to 14.1 and are using Geo and multi-arch containers in your container registry,
we recommend [upgrading](../../administration/geo/replication/upgrading_the_geo_sites.md) to at least GitLab 14.1.
- We found an issue where [Primary sites cannot be removed from the UI](https://gitlab.com/gitlab-org/gitlab/-/issues/338231).
This bug only exists in the UI and does not block the removal of Primary sites using any other method.
If you are running an affected version and need to remove your Primary site, you can manually remove the Primary site
by using the [Geo Sites API](../../api/geo_nodes.md#delete-a-geo-node).
## 14.0.0
Prerequisites:
- The [GitLab 14.0 release post contains several important notes](https://about.gitlab.com/releases/2021/06/22/gitlab-14-0-released/#upgrade)
about pre-requisites including [using Patroni instead of repmgr](https://archives.docs.gitlab.com/15.0/ee/administration/postgresql/replication_and_failover.html#switching-from-repmgr-to-patroni),
migrating to hashed storage and [to Puma](../../administration/operations/puma.md).
- The support of PostgreSQL 11 [has been dropped](../../install/requirements.md#database). Make sure to [update your database](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server) to version 12 before updating to GitLab 14.0.
Long running batched background database migrations:
- Database changes made by the upgrade to GitLab 14.0 can take hours or days to complete on larger GitLab instances.
These [batched background migrations](../background_migrations.md#batched-background-migrations) update whole database tables to mitigate primary key overflow and must be finished before upgrading to GitLab 14.2 or later.
- Due to an issue where `BatchedBackgroundMigrationWorkers` were
[not working](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2785#note_614738345)
for self-managed instances, a [fix was created](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/65106)
that requires an update to at least 14.0.5. The fix was also released in [14.1.0](#1410).
After you update to 14.0.5 or a later 14.0 patch version,
[batched background migrations must finish](../background_migrations.md#batched-background-migrations)
before you upgrade to a later version.
If the migrations are not finished and you try to upgrade to a later version,
you see an error like:
```plaintext
Expected batched background migration for the given configuration to be marked as 'finished', but it is 'active':
```
See how to [resolve this error](../background_migrations_troubleshooting.md#database-migrations-failing-because-of-batched-background-migration-not-finished).
Other issues:
- In GitLab 13.3 some [pipeline processing methods were deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/218536)
and this code was completely removed in GitLab 14.0. If you plan to upgrade from
**GitLab 13.2 or older** directly to 14.0, this is [unsupported](../index.md#upgrading-to-a-new-major-version).
You should instead follow a [supported upgrade path](../index.md#upgrade-paths).
- When [Maintenance mode](../../administration/maintenance_mode/index.md) is
enabled, users cannot sign in with SSO, SAML, or LDAP.
Users who were signed in before Maintenance mode was enabled, continue to be
signed in. If the administrator who enabled Maintenance mode loses their
session, then they can't disable Maintenance mode via the UI. In that case,
you can
[disable Maintenance mode via the API or Rails console](../../administration/maintenance_mode/index.md#disable-maintenance-mode).
[This bug](https://gitlab.com/gitlab-org/gitlab/-/issues/329261) was fixed in
GitLab 14.5.0 and backported into 14.4.3 and 14.3.5.
- **In GitLab 13.12.2 and later**, users with expired passwords can no longer authenticate with API and Git using tokens because of
the [Insufficient Expired Password Validation](https://about.gitlab.com/releases/2021/06/01/security-release-gitlab-13-12-2-released/#insufficient-expired-password-validation)
security fix. If your users get authentication issues following the upgrade, check that their password is not expired:
1. [Connect to the PostgreSQL database](https://docs.gitlab.com/omnibus/settings/database.html#connecting-to-the-postgresql-database) and execute the
following query:
```sql
select id,username,password_expires_at from users where password_expires_at < now();
```
1. If the user is in the returned list, reset the `password_expires_at` for that user:
```sql
update users set password_expires_at = null where username='<USERNAME>';
```
### Linux package installations
- The binaries for PostgreSQL 11 and repmgr have been removed. Before upgrading, you must:
1. Ensure the installation is using [PostgreSQL 12](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server).
1. If using repmgr, [convert to using Patroni](https://archives.docs.gitlab.com/15.0/ee/administration/postgresql/replication_and_failover.html#switching-from-repmgr-to-patroni).
- In GitLab 13.0, `sidekiq-cluster` was enabled by default and the `sidekiq` service ran `sidekiq-cluster` under the hood.
However, users could control this behavior using `sidekiq['cluster']` setting to run Sidekiq directly instead. Users
could also run `sidekiq-cluster` separately using the various `sidekiq_cluster[*]` settings available in `gitlab.rb`.
However these features were deprecated and are now being removed.
Starting with GitLab 14.0, `sidekiq-cluster` becomes the only way to run Sidekiq in Linux package installations. As
part of this process, support for the following settings in `gitlab.rb` is being removed:
- `sidekiq['cluster']` setting. Sidekiq can only be run using `sidekiq-cluster` now.
- `sidekiq_cluster[*]` settings. They should be set via respective `sidekiq[*]` counterparts.
- `sidekiq['concurrency']` setting. The limits should be controlled using the two settings `sidekiq['min_concurrency']`
and `sidekiq['max_concurrency']`.
- In GitLab 13.0, Puma became the default web server for GitLab, but users were still able to continue using Unicorn if
needed. Starting with GitLab 14.0, Unicorn is no longer supported as a webserver for GitLab and is no longer shipped
with the Linux package.
Users must migrate to Puma following [the documentation](../../administration/operations/puma.md) to upgrade to GitLab
14.0.
- The Consul version has been updated from 1.6.10 to 1.9.6 for Geo and multi-node PostgreSQL installs. Its important
that Consul nodes be upgraded and restarted one at a time.
For more information, see [Upgrade the Consul nodes](../../administration/consul.md#upgrade-the-consul-nodes).
- Starting with GitLab 14.0, GitLab automatically generates a password for initial administrator user (`root`) and stores
this value to `/etc/gitlab/initial_root_password`.
For more information, see
[Set up the initial password](https://docs.gitlab.com/omnibus/installation/index.html#set-up-the-initial-password).
- Two configuration options for Redis were deprecated in GitLab 13 and removed in GitLab 14:
- `redis_slave_role` is replaced with `redis_replica_role`.
- `redis['client_output_buffer_limit_slave']` is replaced with `redis['client_output_buffer_limit_replica']`.
Redis Cache nodes being upgraded from GitLab 13.12 to 14.0 that still refer to `redis_slave_role` in `gitlab.rb` will
encounter an error in the output of `gitlab-ctl reconfigure`:
```plaintext
There was an error running gitlab-ctl reconfigure:
The following invalid roles have been set in 'roles': redis_slave_role
```
### Geo installations
DETAILS:
**Tier:** Premium, Ultimate
**Offering:** Self-managed
- We found an issue where [Primary sites cannot be removed from the UI](https://gitlab.com/gitlab-org/gitlab/-/issues/338231).
This bug only exists in the UI and does not block the removal of Primary sites using any other method.
If you are running an affected version and need to remove your Primary site, you can manually remove the Primary site
by using the [Geo Sites API](../../api/geo_nodes.md#delete-a-geo-node).
### Upgrading to later 14.Y releases
- Instances running 14.0.0 - 14.0.4 should not upgrade directly to GitLab 14.2 or later,
because of [batched background migrations](../background_migrations.md#batched-background-migrations).
1. Upgrade first to either:
- 14.0.5 or a later 14.0.Z patch release.
- 14.1.0 or a later 14.1.Z patch release.
1. [Batched background migrations must finish](../background_migrations.md#batched-background-migrations)
before you upgrade to a later version [and may take longer than usual](#1400).
<!--- end_remove -->
<!-- This redirect file can be deleted after <2024-12-11>. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->

21
doc/user/group/saml_sso/troubleshooting.md
View File

@ -23,6 +23,8 @@ SAML responses are base64 encoded, so we recommend the following browser plugins
- [SAML-tracer](https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/) for Firefox.
- [SAML Message Decoder](https://chromewebstore.google.com/detail/mpabchoaimgbdbbjjieoaeiibojelbhm?hl=en) for Chrome.
If you cannot install a browser plugin, you can [manually generate and capture a SAML response](#manually-generate-a-saml-response) instead.
Pay specific attention to:
- The `NameID`, which we use to identify which user is signing in. If the user has previously signed in, this
@ -52,6 +54,25 @@ To generate a SAML Response:
[example SAML response](index.md#example-saml-response).
1. Within the SAML tracer, select the **Export** icon to save the response in JSON format.
#### Manually generate a SAML response
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
For an overview, see this [video on manually generating a SAML response without using a browser plugin (using Google Chrome)](https://youtu.be/umMPj6ohF_I), uploaded by GitLab Support.
<!-- Video published on 2024-09-09 -->
Regardless of what browser you use, the process is similar to the following:
1. Right-click on a new browser and click on **Inspect** to open the **DevTools** window.
1. Select the **Network** tab. Make sure that **Preserve log** is selected.
1. Switch to the browser page and sign in to GitLab using SAML SSO.
1. Switch back to the **DevTools** window and filter for the `callback` event.
1. Select the **Payload** tab for the callback event and right-click to copy the value.
1. Paste this value into the following command: `echo "<value>" | base64 --decode > saml_response.xml`.
1. Open `saml_response.xml` in a code editor.
If you have an XML "prettifier" installed in your code editor, you should be able to automatically
format the response to be easier to read.
## Search Rails logs for a SAML sign-in
DETAILS:

4
doc/user/profile/service_accounts.md
View File

@ -78,12 +78,12 @@ Prerequisites:
- You must be an administrator for your self-managed instance.
1. [Create a service account](../../api/users.md#create-service-account-user).
1. [Create a service account](../../api/user_service_accounts.md#create-a-service-account-user).
This service account is associated with the entire instance, not a specific group
or project in the instance.
1. [List all service account users](../../api/users.md#list-service-account-users).
1. [List all service account users](../../api/user_service_accounts.md#list-all-service-account-users).
1. [Create a personal access token](../../api/user_tokens.md#create-a-personal-access-token)
for the service account user.

3
doc/user/project/integrations/google_artifact_management.md
View File

@ -9,13 +9,10 @@ info: To determine the technical writer assigned to the Stage/Group associated w
DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** GitLab.com
**Status:** Beta
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/141127) in GitLab 16.10 [with a flag](../../../administration/feature_flags.md) named `google_cloud_support_feature_flag`. This feature is in [beta](../../../policy/experiment-beta-support.md).
> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/150472) in GitLab 17.1. Feature flag `google_cloud_support_feature_flag` removed.
This feature is in [beta](../../../policy/experiment-beta-support.md).
You can use the Google Artifact Management integration to
configure and connect a [Google Artifact Registry](https://cloud.google.com/artifact-registry) repository to your GitLab project.

10
doc/user/project/protected_tags.md
View File

@ -125,6 +125,16 @@ To allow a deploy key to create a protected tag:
1. From the **Allowed to create** list, select the deploy key.
1. Select **Protect**.
## Run pipelines on protected tags
The permissions to create protected tags define if a user can:
- Initiate and run CI/CD pipelines.
- Execute actions on jobs associated with these tags.
These permissions ensure that only authorized users can trigger and manage
CI/CD processes for protected tags.
## Delete a protected tag
You can manually delete protected tags with the GitLab API, or the

1
lib/api/alert_management_alerts.rb
View File

@ -25,7 +25,6 @@ module API
authorize!(:upload_alert_management_metric_image, find_project_alert(request.params[:alert_iid]))
require_gitlab_workhorse!
::Gitlab::Workhorse.verify_api_request!(request.headers)
status 200
content_type ::Gitlab::Workhorse::INTERNAL_API_CONTENT_TYPE

2
lib/api/group_import.rb
View File

@ -37,8 +37,6 @@ module API
post 'import/authorize' do
require_gitlab_workhorse!
Gitlab::Workhorse.verify_api_request!(headers)
status 200
content_type Gitlab::Workhorse::INTERNAL_API_CONTENT_TYPE

2
lib/api/helpers/packages_helpers.rb
View File

@ -55,8 +55,6 @@ module API
authorize_upload!(subject)
Gitlab::Workhorse.verify_api_request!(headers)
status 200
content_type Gitlab::Workhorse::INTERNAL_API_CONTENT_TYPE

77
lib/gitlab/background_migration/backfill_project_id_to_dependency_list_exports.rb Normal file
View File

@ -0,0 +1,77 @@
# frozen_string_literal: true
module Gitlab
module BackgroundMigration
class BackfillProjectIdToDependencyListExports < BatchedMigrationJob
operation_name :backfill_project_id_to_dependency_list_exports
scope_to ->(relation) { relation.where.not(pipeline_id: nil) }
feature_category :dependency_management
class DependencyListExport < ::ApplicationRecord
FINISHED = 2
FAILED = -1
self.table_name = 'dependency_list_exports'
end
class Pipeline < ::Ci::ApplicationRecord
self.table_name = 'p_ci_pipelines'
end
def perform
each_sub_batch do |exports|
pipelines = Pipeline.id_in(exports.map(&:pipeline_id))
export_ids_to_delete = []
tuples_to_update = exports.filter_map do |export|
pipeline = pipelines.find { |pipeline| pipeline.id == export.pipeline_id }
if pipeline.blank? || dangling?(export)
export_ids_to_delete.push(export.id)
next
end
[export.id, pipeline.project_id] if export.project_id != pipeline.project_id
end
DependencyListExport.id_in(export_ids_to_delete).delete_all
bulk_update!(tuples_to_update)
end
end
def bulk_update!(tuples)
return if tuples.blank?
values_sql = Arel::Nodes::ValuesList.new(tuples).to_sql
sql = <<~SQL
UPDATE
dependency_list_exports
SET
project_id = tuples.project_id
FROM
(#{values_sql}) AS tuples(export_id, project_id)
WHERE
dependency_list_exports.id = tuples.export_id;
SQL
DependencyListExport.connection.execute(sql)
end
def completed?(export)
export.status.in?([DependencyListExport::FINISHED, DependencyListExport::FAILED])
end
def stale?(export)
# We delete exports one hour after completion and runtime
# is upwards of 30 mins.
export.updated_at < 3.hours.ago
end
def dangling?(export)
completed?(export) && stale?(export)
end
end
end
end

8
lib/gitlab/background_migration/fix_vulnerability_reads_has_issues.rb
View File

@ -18,8 +18,12 @@ module Gitlab
# rubocop:enable Style/Documentation
def perform
each_sub_batch do |sub_batch|
vulnerability_reads_with_issue_links(sub_batch).update_all('has_issues = true')
Gitlab::Database.allow_cross_joins_across_databases(
url: 'https://gitlab.com/gitlab-org/gitlab/-/issues/480746'
) do
each_sub_batch do |sub_batch|
vulnerability_reads_with_issue_links(sub_batch).update_all('has_issues = true')
end
end
end

4
lib/gitlab/database/loose_foreign_keys.rb
View File

@ -22,7 +22,9 @@ module Gitlab
{
column: config.fetch('column'),
on_delete: config.fetch('on_delete').to_sym,
gitlab_schema: GitlabSchema.table_schema!(child_table_name)
gitlab_schema: GitlabSchema.table_schema!(child_table_name),
target_column: config['target_column'],
target_value: config['target_value']
}
)
end

48
locale/gitlab.pot
View File

@ -13964,11 +13964,6 @@ msgstr ""
msgid "ComplianceFrameworks|\"%{name}\" is a reserved word and cannot be used as a compliance framework name."
msgstr ""
msgid "ComplianceFrameworks|%{count} linked policy."
msgid_plural "ComplianceFrameworks|%{count} linked policies."
msgstr[0] ""
msgstr[1] ""
msgid "ComplianceFrameworks|A compliance frameworks CSV export for the group \"%{group_name}\" is attached to this email."
msgstr ""
@ -13978,6 +13973,9 @@ msgstr ""
msgid "ComplianceFrameworks|Add framework"
msgstr ""
msgid "ComplianceFrameworks|All selected projects will be covered by the framework’s selected requirements and the policies."
msgstr ""
msgid "ComplianceFrameworks|Background color"
msgstr ""
@ -14005,7 +14003,7 @@ msgstr ""
msgid "ComplianceFrameworks|Configuration not found"
msgstr ""
msgid "ComplianceFrameworks|Create a compliance framework"
msgid "ComplianceFrameworks|Create framework"
msgstr ""
msgid "ComplianceFrameworks|Default framework will be applied automatically to any new project created in the group or sub group."
@ -14023,15 +14021,21 @@ msgstr ""
msgid "ComplianceFrameworks|Description is required"
msgstr ""
msgid "ComplianceFrameworks|Edit a compliance framework"
msgstr ""
msgid "ComplianceFrameworks|Edit compliance framework"
msgstr ""
msgid "ComplianceFrameworks|Edit compliance framework: %{frameworkName}"
msgstr ""
msgid "ComplianceFrameworks|Error fetching compliance frameworks data. Please refresh the page or try a different framework"
msgstr ""
msgid "ComplianceFrameworks|Go to the %{linkStart}compliance center / project page%{linkEnd} to apply projects for this framework."
msgstr ""
msgid "ComplianceFrameworks|Go to the %{linkStart}policy management page%{linkEnd} to scope policies for this framework."
msgstr ""
msgid "ComplianceFrameworks|Invalid format"
msgstr ""
@ -14050,9 +14054,6 @@ msgstr ""
msgid "ComplianceFrameworks|Name is required, and must be less than 255 characters"
msgstr ""
msgid "ComplianceFrameworks|Name, description"
msgstr ""
msgid "ComplianceFrameworks|New compliance framework"
msgstr ""
@ -14068,7 +14069,10 @@ msgstr ""
msgid "ComplianceFrameworks|No frameworks found. Create a framework in top-level group %{linkStart}namespace%{linkEnd} to assign it to a project."
msgstr ""
msgid "ComplianceFrameworks|Policy"
msgid "ComplianceFrameworks|Optional"
msgstr ""
msgid "ComplianceFrameworks|Policies"
msgstr ""
msgid "ComplianceFrameworks|Policy name"
@ -14083,6 +14087,9 @@ msgstr ""
msgid "ComplianceFrameworks|Projects"
msgstr ""
msgid "ComplianceFrameworks|Required"
msgstr ""
msgid "ComplianceFrameworks|Required format: %{codeStart}path/file.y[a]ml@group-name/project-name%{codeEnd}. %{linkStart}See some examples%{linkEnd}."
msgstr ""
@ -14092,9 +14099,15 @@ msgstr ""
msgid "ComplianceFrameworks|Saved changes to compliance framework"
msgstr ""
msgid "ComplianceFrameworks|Select policies to enforce on all projects scoped to this framework."
msgstr ""
msgid "ComplianceFrameworks|Set as default"
msgstr ""
msgid "ComplianceFrameworks|Set basic information for the compliance framework."
msgstr ""
msgid "ComplianceFrameworks|Set compliance pipeline configuration for projects that use this framework. %{linkStart}How do I create the configuration?%{linkEnd}"
msgstr ""
@ -14116,12 +14129,6 @@ msgstr ""
msgid "ComplianceFrameworks|To unlink this policy and framework, edit the policy's scope."
msgstr ""
msgid "ComplianceFrameworks|Total policies in the group: %{count}"
msgstr ""
msgid "ComplianceFrameworks|Total projects linked to framework: %{count}"
msgstr ""
msgid "ComplianceFrameworks|Unable to save this compliance framework. Please try again"
msgstr ""
@ -58101,6 +58108,9 @@ msgstr ""
msgid "Update failed"
msgstr ""
msgid "Update framework"
msgstr ""
msgid "Update it"
msgstr ""

2
package.json
View File

@ -79,7 +79,7 @@
"@mattiasbuelens/web-streams-adapter": "^0.1.0",
"@rails/actioncable": "7.0.8-4",
"@rails/ujs": "7.0.8-4",
"@sentry/browser": "8.27.0",
"@sentry/browser": "8.28.0",
"@snowplow/browser-plugin-client-hints": "^3.24.2",
"@snowplow/browser-plugin-form-tracking": "^3.24.2",
"@snowplow/browser-plugin-ga-cookies": "^3.24.2",

117
spec/frontend/sessions/new/components/email_form_spec.js Normal file
View File

@ -0,0 +1,117 @@
import { GlForm, GlFormInput } from '@gitlab/ui';
import { nextTick } from 'vue';
import { mountExtended } from 'helpers/vue_test_utils_helper';
import EmailForm from '~/sessions/new/components/email_form.vue';
import { I18N_CANCEL, I18N_EMAIL_INVALID } from '~/sessions/new/constants';
const validEmailAddress = 'foo+bar@ema.il';
const invalidEmailAddress = 'invalid@ema@il';
describe('EmailForm', () => {
let wrapper;
const defaultProps = {
error: '',
formInfo: 'Form info',
submitText: 'Submit',
};
const createComponent = (props = {}) => {
wrapper = mountExtended(EmailForm, {
propsData: { ...defaultProps, ...props },
});
};
const findForm = () => wrapper.findComponent(GlForm);
const findEmailInput = () => wrapper.findComponent(GlFormInput);
const findSubmitButton = () => wrapper.find('[type="submit"]');
const findCancelLink = () => wrapper.findByText(I18N_CANCEL);
const enterEmail = (email) => findEmailInput().setValue(email);
const submitForm = () => findForm().trigger('submit');
beforeEach(() => {
createComponent();
});
it('displays the correct submit button text', () => {
expect(findSubmitButton().text()).toContain(defaultProps.submitText);
});
it('displays the passed in form info text', () => {
expect(wrapper.text()).toContain(defaultProps.formInfo);
});
describe('on submit', () => {
it('emits a submit-email event with the submitted email address', () => {
enterEmail(validEmailAddress);
submitForm();
expect(wrapper.emitted('submit-email')[0]).toEqual([validEmailAddress]);
});
});
describe('error messages', () => {
describe('when trying to submit an invalid email address', () => {
beforeEach(() => {
enterEmail(invalidEmailAddress);
});
it('shows no error message before submitting the form', () => {
expect(wrapper.text()).not.toContain(I18N_EMAIL_INVALID);
expect(findSubmitButton().props('disabled')).toBe(false);
});
describe('when submitting the form', () => {
beforeEach(() => {
submitForm();
});
it('shows an error message and disables the submit button', () => {
expect(wrapper.text()).toContain(I18N_EMAIL_INVALID);
expect(findSubmitButton().props('disabled')).toBe(true);
});
describe('when entering a valid email address', () => {
beforeEach(() => {
enterEmail(validEmailAddress);
});
it('hides the error message and enables the submit button again', () => {
expect(wrapper.text()).not.toContain(I18N_EMAIL_INVALID);
expect(findSubmitButton().props('disabled')).toBe(false);
});
});
});
});
describe('when error prop is not an empty string', () => {
it('shows the error message and disables the submit button', async () => {
const serverErrorMessage = 'server error message';
createComponent({ error: serverErrorMessage });
expect(wrapper.text()).not.toContain(serverErrorMessage);
enterEmail(validEmailAddress);
await nextTick();
submitForm();
await nextTick();
expect(wrapper.text()).toContain(serverErrorMessage);
expect(findSubmitButton().props('disabled')).toBe(true);
});
});
});
describe('when clicking the cancel link', () => {
beforeEach(() => {
findCancelLink().trigger('click');
});
it('emits a cancel event', () => {
expect(wrapper.emitted('cancel')[0]).toEqual([]);
});
});
});

2
spec/frontend/sessions/new/components/email_verification_spec.js
View File

@ -32,12 +32,12 @@ describe('EmailVerification', () => {
verifyPath: '/users/sign_in',
resendPath: '/users/resend_verification_code',
isOfferEmailReset: true,
updateEmailPath: '/users/update_email',
};
const createComponent = (props = {}) => {
wrapper = mountExtended(EmailVerification, {
propsData: { ...defaultPropsData, ...props },
provide: { updateEmailPath: '/users/update_email' },
});
};

130
spec/frontend/sessions/new/components/update_email_spec.js
View File

@ -1,48 +1,40 @@
import { GlForm, GlFormInput } from '@gitlab/ui';
import axios from 'axios';
import MockAdapter from 'axios-mock-adapter';
import { mountExtended } from 'helpers/vue_test_utils_helper';
import { createAlert, VARIANT_SUCCESS } from '~/alert';
import { HTTP_STATUS_NOT_FOUND, HTTP_STATUS_OK } from '~/lib/utils/http_status';
import UpdateEmail from '~/sessions/new/components/update_email.vue';
import EmailForm from '~/sessions/new/components/email_form.vue';
import {
I18N_CANCEL,
I18N_EMAIL_INVALID,
I18N_UPDATE_EMAIL,
I18N_UPDATE_EMAIL_GUIDANCE,
I18N_UPDATE_EMAIL_SUCCESS,
I18N_GENERIC_ERROR,
SUCCESS_RESPONSE,
FAILURE_RESPONSE,
} from '~/sessions/new/constants';
const validEmailAddress = 'foo+bar@ema.il';
const invalidEmailAddress = 'invalid@ema@il';
const email = 'foo+bar@ema.il';
jest.mock('~/alert');
jest.mock('~/lib/utils/url_utility', () => ({
...jest.requireActual('~/lib/utils/url_utility'),
visitUrl: jest.fn(),
}));
describe('EmailVerification', () => {
describe('UpdateEmail', () => {
let wrapper;
let axiosMock;
const defaultPropsData = {
const provide = {
updateEmailPath: '/users/update_email',
};
const createComponent = (props = {}) => {
wrapper = mountExtended(UpdateEmail, {
propsData: { ...defaultPropsData, ...props },
});
const createComponent = () => {
wrapper = mountExtended(UpdateEmail, { provide });
};
const findForm = () => wrapper.findComponent(GlForm);
const findEmailInput = () => wrapper.findComponent(GlFormInput);
const findSubmitButton = () => wrapper.find('[type="submit"]');
const findCancelLink = () => wrapper.findByText(I18N_CANCEL);
const enterEmail = (email) => findEmailInput().setValue(email);
const submitForm = () => findForm().trigger('submit');
const findEmailForm = () => wrapper.findComponent(EmailForm);
const submitEmailForm = () => findEmailForm().vm.$emit('submit-email', email);
const mockUpdateEmailEndpoint = (response) => {
axiosMock.onPatch(provide.updateEmailPath, { user: { email } }).reply(HTTP_STATUS_OK, response);
};
beforeEach(() => {
axiosMock = new MockAdapter(axios);
@ -54,15 +46,19 @@ describe('EmailVerification', () => {
axiosMock.restore();
});
it('renders EmailForm with the correct props', () => {
expect(findEmailForm().props()).toMatchObject({
error: '',
formInfo: I18N_UPDATE_EMAIL_GUIDANCE,
submitText: I18N_UPDATE_EMAIL,
});
});
describe('when successfully verifying the email address', () => {
beforeEach(async () => {
enterEmail(validEmailAddress);
mockUpdateEmailEndpoint({ status: SUCCESS_RESPONSE });
submitEmailForm();
axiosMock
.onPatch(defaultPropsData.updateEmailPath)
.reply(HTTP_STATUS_OK, { status: SUCCESS_RESPONSE });
submitForm();
await axios.waitForAll();
});
@ -74,74 +70,21 @@ describe('EmailVerification', () => {
});
it('emits a verifyToken event with the updated email address', () => {
expect(wrapper.emitted('verifyToken')[0]).toEqual([validEmailAddress]);
expect(wrapper.emitted('verifyToken')[0]).toEqual([email]);
});
});
describe('error messages', () => {
beforeEach(() => {
enterEmail(invalidEmailAddress);
});
describe('when trying to submit an invalid email address', () => {
it('shows no error message before submitting the form', () => {
expect(wrapper.text()).not.toContain(I18N_EMAIL_INVALID);
expect(findSubmitButton().props('disabled')).toBe(false);
});
describe('when submitting the form', () => {
beforeEach(async () => {
submitForm();
await axios.waitForAll();
});
it('shows an error message and disables the submit button', () => {
expect(wrapper.text()).toContain(I18N_EMAIL_INVALID);
expect(findSubmitButton().props('disabled')).toBe(true);
});
describe('when entering a valid email address', () => {
beforeEach(() => {
enterEmail(validEmailAddress);
});
it('hides the error message and enables the submit button again', () => {
expect(wrapper.text()).not.toContain(I18N_EMAIL_INVALID);
expect(findSubmitButton().props('disabled')).toBe(false);
});
});
});
});
describe('when the server responds with an error message', () => {
const serverErrorMessage = 'server error message';
it('passes the error as error prop to EmailForm', async () => {
const serverErrorMessage = 'server error message';
beforeEach(async () => {
enterEmail(validEmailAddress);
mockUpdateEmailEndpoint({ status: FAILURE_RESPONSE, message: serverErrorMessage });
submitEmailForm();
axiosMock
.onPatch(defaultPropsData.updateEmailPath)
.replyOnce(HTTP_STATUS_OK, { status: FAILURE_RESPONSE, message: serverErrorMessage });
submitForm();
await axios.waitForAll();
});
it('shows the error message and disables the submit button', () => {
expect(wrapper.text()).toContain(serverErrorMessage);
expect(findSubmitButton().props('disabled')).toBe(true);
});
describe('when entering a valid email address', () => {
beforeEach(async () => {
await enterEmail('');
enterEmail(validEmailAddress);
});
it('hides the error message and enables the submit button again', () => {
expect(wrapper.text()).not.toContain(serverErrorMessage);
expect(findSubmitButton().props('disabled')).toBe(false);
});
expect(findEmailForm().props('error')).toBe(serverErrorMessage);
});
});
@ -151,11 +94,8 @@ describe('EmailVerification', () => {
${'the response is undefined'} | ${HTTP_STATUS_OK}
${'the request failed'} | ${HTTP_STATUS_NOT_FOUND}
`(`shows an alert when $scenario`, async ({ statusCode }) => {
enterEmail(validEmailAddress);
axiosMock.onPatch(defaultPropsData.updateEmailPath).replyOnce(statusCode);
submitForm();
axiosMock.onPatch(provide.updateEmailPath).replyOnce(statusCode);
submitEmailForm();
await axios.waitForAll();
@ -168,12 +108,10 @@ describe('EmailVerification', () => {
});
});
describe('when clicking the cancel link', () => {
beforeEach(() => {
findCancelLink().trigger('click');
});
describe('when EmailForm emits cancel event', () => {
it('emits a verifyToken event without an email address', () => {
findEmailForm().vm.$emit('cancel');
expect(wrapper.emitted('verifyToken')[0]).toEqual([]);
});
});

14
spec/lib/api/helpers/packages_helpers_spec.rb
View File

@ -114,17 +114,25 @@ RSpec.describe API::Helpers::PackagesHelpers, feature_category: :package_registr
end
describe '#authorize_workhorse!' do
let_it_be(:headers) { {} }
let_it_be(:headers) { { 'HTTP_GITLAB_WORKHORSE' => 1 } }
let_it_be(:params) { { subject: project } }
let(:env) { headers }
let(:request) { ActionDispatch::Request.new(env) }
subject { helper.authorize_workhorse!(**params) }
shared_examples 'workhorse authorize' do
before do
allow(helper).to receive(:request).and_return(request)
allow(helper).to receive(:env).and_return(env)
end
it 'authorizes workhorse' do
expect(helper).to receive(:authorize_upload!).with(project)
expect(helper).to receive(:authorize_create_package!).with(project)
expect(helper).to receive(:status).with(200)
expect(helper).to receive(:content_type).with(Gitlab::Workhorse::INTERNAL_API_CONTENT_TYPE)
expect(Gitlab::Workhorse).to receive(:verify_api_request!).with(headers)
expect(Gitlab::Workhorse).to receive(:verify_api_request!).with(request.headers)
expect(::Packages::PackageFileUploader).to receive(:workhorse_authorize).with(workhorse_authorize_params)
expect(subject).to eq nil

85
spec/lib/gitlab/background_migration/backfill_project_id_to_dependency_list_exports_spec.rb Normal file
View File

@ -0,0 +1,85 @@
# frozen_string_literal: true
require 'spec_helper'
RSpec.describe Gitlab::BackgroundMigration::BackfillProjectIdToDependencyListExports, feature_category: :dependency_management do
let(:dependency_list_exports) { table(:dependency_list_exports) }
let(:pipelines) { partitioned_table(:p_ci_pipelines, database: :ci) }
let(:projects) { table(:projects) }
let(:namespaces) { table(:namespaces) }
let!(:pipeline) { create_ci_pipeline('pipeline-1') }
let(:args) do
min, max = dependency_list_exports.pick('MIN(id)', 'MAX(id)')
{
start_id: min,
end_id: max,
batch_table: 'dependency_list_exports',
batch_column: 'id',
sub_batch_size: 1,
pause_ms: 0,
connection: ApplicationRecord.connection
}
end
subject(:perform_migration) { described_class.new(**args).perform }
context 'when export is missing project_id' do
let!(:export) { dependency_list_exports.create!(pipeline_id: pipeline.id) }
let!(:other_pipeline) { create_ci_pipeline('pipeline-2') }
let!(:export_on_same_pipeline) { dependency_list_exports.create!(pipeline_id: pipeline.id) }
let!(:export_on_different_pipeline) { dependency_list_exports.create!(pipeline_id: other_pipeline.id) }
it 'sets the project_id to build.project_id' do
expect { perform_migration }.to change { export.reload.project_id }.from(nil).to(pipeline.project_id)
.and change { export_on_same_pipeline.reload.project_id }.from(nil).to(pipeline.project_id)
.and change { export_on_different_pipeline.reload.project_id }.from(nil).to(other_pipeline.project_id)
end
end
context 'when export pipeline does not exist' do
let!(:export) { dependency_list_exports.create!(pipeline_id: non_existing_record_id) }
it 'deletes the export' do
expect { perform_migration }.to change { dependency_list_exports.count }.from(1).to(0)
end
end
context 'when export is dangling' do
let!(:export) { dependency_list_exports.create!(pipeline_id: pipeline.id, status: 2, updated_at: 1.month.ago) }
it 'deletes the export' do
expect { perform_migration }.to change { dependency_list_exports.count }.from(1).to(0)
end
end
context 'when export finished recently' do
let!(:export) { dependency_list_exports.create!(pipeline_id: pipeline.id, status: 2, updated_at: 5.minutes.ago) }
it 'does not delete the export' do
expect { perform_migration }.not_to change { dependency_list_exports.count }
end
end
context 'when export is not completed' do
let!(:export) { dependency_list_exports.create!(pipeline_id: pipeline.id, status: 1, updated_at: 2.hours.ago) }
it 'does not delete the export' do
expect { perform_migration }.not_to change { dependency_list_exports.count }
end
end
def create_ci_pipeline(name)
namespace = namespaces.create!(name: "group-#{name}", path: "group-#{name}")
project_namespace = namespaces.create!(name: "project-#{name}", path: "project-#{name}")
project = projects.create!(
namespace_id: namespace.id,
project_namespace_id: project_namespace.id,
name: "project-#{name}",
path: "project-#{name}"
)
pipelines.create!(project_id: project.id, partition_id: 100)
end
end

17
spec/lib/gitlab/database/loose_foreign_keys_spec.rb
View File

@ -11,7 +11,9 @@ RSpec.describe Gitlab::Database::LooseForeignKeys do
options: a_hash_including(
column: be_a(String),
gitlab_schema: be_in(Gitlab::Database.schemas_to_base_models.symbolize_keys.keys),
on_delete: be_in([:async_delete, :async_nullify])
on_delete: be_in([:async_delete, :async_nullify, :update_column_to]),
target_column: be_a(String).or(be_a(NilClass)),
target_value: be_a(String).or(be_a(Integer)).or(be_a(NilClass))
),
from_table: be_a(String),
to_table: be_a(String)
@ -49,7 +51,13 @@ RSpec.describe Gitlab::Database::LooseForeignKeys do
it 'does not have duplicate column definitions' do
# ignore other modifiers
all_definitions = definitions.map do |definition|
{ from_table: definition.from_table, to_table: definition.to_table, column: definition.column }
{
from_table: definition.from_table,
to_table: definition.to_table,
column: definition.column,
target_column: definition.options[:target_column],
target_value: definition.options[:target_value]
}
end
# expect to not have duplicates
@ -79,6 +87,11 @@ RSpec.describe Gitlab::Database::LooseForeignKeys do
"Table #{definition.from_table} does not exist"
expect(model.connection).to be_column_exist(definition.from_table, definition.column),
"Column #{definition.column} in #{definition.from_table} does not exist"
if definition.options[:target_column]
expect(model.connection).to be_column_exist(definition.from_table, definition.options[:target_column]),
"Column #{definition.options[:target_column]} in #{definition.from_table} does not exist"
end
end
end
end

1
spec/lib/gitlab/database/sharding_key_spec.rb
View File

@ -65,6 +65,7 @@ RSpec.describe 'new tables missing sharding_key', feature_category: :cell do
'ci_job_artifacts.project_id',
'ci_namespace_monthly_usages.namespace_id', # https://gitlab.com/gitlab-org/gitlab/-/issues/321400
'ci_builds_metadata.project_id',
'p_ci_job_annotations.project_id', # LFK already present on p_ci_builds and cascade delete all ci resources
'ldap_group_links.group_id',
'namespace_descendants.namespace_id',
'p_batched_git_ref_updates_deletions.project_id',

2
spec/migrations/20240613064362_queue_backfill_vulnerability_issue_links_project_id_spec.rb
View File

@ -19,7 +19,7 @@ RSpec.describe QueueBackfillVulnerabilityIssueLinksProjectId, feature_category:
interval: described_class::DELAY_INTERVAL,
batch_size: described_class::BATCH_SIZE,
sub_batch_size: described_class::SUB_BATCH_SIZE,
gitlab_schema: :gitlab_main_cell,
gitlab_schema: :gitlab_sec,
job_arguments: [
:project_id,
:vulnerabilities,

26
spec/migrations/20240829182925_queue_backfill_project_id_to_dependency_list_exports_spec.rb Normal file
View File

@ -0,0 +1,26 @@
# frozen_string_literal: true
require 'spec_helper'
require_migration!
RSpec.describe QueueBackfillProjectIdToDependencyListExports, feature_category: :dependency_management do
let!(:batched_migration) { described_class::MIGRATION }
it 'schedules a new batched migration' do
reversible_migration do |migration|
migration.before -> {
expect(batched_migration).not_to have_scheduled_batched_migration
}
migration.after -> {
expect(batched_migration).to have_scheduled_batched_migration(
table_name: :dependency_list_exports,
column_name: :id,
interval: described_class::DELAY_INTERVAL,
batch_size: described_class::BATCH_SIZE,
sub_batch_size: described_class::SUB_BATCH_SIZE
)
}
end
end
end

61
spec/services/loose_foreign_keys/batch_cleaner_service_spec.rb
View File

@ -18,6 +18,11 @@ RSpec.describe LooseForeignKeys::BatchCleanerService, feature_category: :databas
t.bigint :parent_id_with_different_column
end
migration.create_table :_test_loose_fk_child_table_3 do |t|
t.bigint :parent_id
t.integer :status, limit: 2
end
migration.track_record_deletions(:_test_loose_fk_parent_table)
end
@ -40,6 +45,17 @@ RSpec.describe LooseForeignKeys::BatchCleanerService, feature_category: :databas
on_delete: :async_nullify,
gitlab_schema: :gitlab_main
}
),
ActiveRecord::ConnectionAdapters::ForeignKeyDefinition.new(
'_test_loose_fk_child_table_3',
'_test_loose_fk_parent_table',
{
column: 'parent_id',
on_delete: :update_column_to,
gitlab_schema: :gitlab_main,
target_column: 'status',
target_value: 4
}
)
]
end
@ -47,6 +63,7 @@ RSpec.describe LooseForeignKeys::BatchCleanerService, feature_category: :databas
let(:loose_fk_parent_table) { table(:_test_loose_fk_parent_table) }
let(:loose_fk_child_table_1) { table(:_test_loose_fk_child_table_1) }
let(:loose_fk_child_table_2) { table(:_test_loose_fk_child_table_2) }
let(:loose_fk_child_table_3) { table(:_test_loose_fk_child_table_3) }
let(:parent_record_1) { loose_fk_parent_table.create! }
let(:other_parent_record) { loose_fk_parent_table.create! }
@ -70,6 +87,13 @@ RSpec.describe LooseForeignKeys::BatchCleanerService, feature_category: :databas
# these will not be deleted
loose_fk_child_table_2.create!(parent_id_with_different_column: other_parent_record.id)
loose_fk_child_table_2.create!(parent_id_with_different_column: other_parent_record.id)
loose_fk_child_table_3.create!(parent_id: parent_record_1.id, status: 1)
loose_fk_child_table_3.create!(parent_id: parent_record_1.id, status: 1)
# these will not be updated
loose_fk_child_table_3.create!(parent_id: other_parent_record.id, status: 1)
loose_fk_child_table_3.create!(parent_id: other_parent_record.id, status: 1)
end
after(:all) do
@ -77,6 +101,7 @@ RSpec.describe LooseForeignKeys::BatchCleanerService, feature_category: :databas
migration.drop_table :_test_loose_fk_parent_table
migration.drop_table :_test_loose_fk_child_table_1
migration.drop_table :_test_loose_fk_child_table_2
migration.drop_table :_test_loose_fk_child_table_3
end
context 'when parent records are deleted' do
@ -101,6 +126,10 @@ RSpec.describe LooseForeignKeys::BatchCleanerService, feature_category: :databas
expect(loose_fk_child_table_2.where(parent_id_with_different_column: nil).count).to eq(2)
end
it 'updates the child records' do
expect(loose_fk_child_table_3.where(parent_id: parent_record_1.id, status: 4).count).to eq(2)
end
it 'cleans up the pending parent DeletedRecord' do
expect(LooseForeignKeys::DeletedRecord.status_pending.count).to eq(0)
expect(LooseForeignKeys::DeletedRecord.status_processed.count).to eq(1)
@ -116,6 +145,38 @@ RSpec.describe LooseForeignKeys::BatchCleanerService, feature_category: :databas
expect(loose_fk_child_table_1.where(parent_id: other_parent_record.id).count).to eq(2)
expect(loose_fk_child_table_2.where(parent_id_with_different_column: other_parent_record.id).count).to eq(2)
end
it 'does not update unrelated records' do
expect(loose_fk_child_table_3.where(parent_id: other_parent_record.id, status: 1).count).to eq(2)
end
end
context 'when loose_foreign_keys_update_column_to is disabled' do
before do
stub_feature_flags(loose_foreign_keys_update_column_to: false)
end
context 'when parent records are deleted' do
let(:deleted_records_counter) { Gitlab::Metrics.registry.get(:loose_foreign_key_processed_deleted_records) }
before do
parent_record_1.delete
expect(loose_fk_child_table_1.count).to eq(4)
expect(loose_fk_child_table_2.count).to eq(4)
described_class.new(
parent_table: '_test_loose_fk_parent_table',
loose_foreign_key_definitions: loose_foreign_key_definitions,
deleted_parent_records: LooseForeignKeys::DeletedRecord.load_batch_for_table('public._test_loose_fk_parent_table', 100),
connection: ::ApplicationRecord.connection
).execute
end
it 'does not update the child records' do
expect(loose_fk_child_table_3.where(parent_id: parent_record_1.id, status: 4).count).to eq(0)
end
end
end
context 'when the child table is partitioned' do

39
spec/services/loose_foreign_keys/cleaner_service_spec.rb
View File

@ -46,7 +46,7 @@ RSpec.describe LooseForeignKeys::CleanerService, feature_category: :database do
describe 'query generation' do
context 'when single primary key is used' do
let(:issue) { create(:issue) }
let(:issue) { create(:issue, :opened) }
let(:deleted_records) do
[
@ -74,6 +74,43 @@ RSpec.describe LooseForeignKeys::CleanerService, feature_category: :database do
expect(Issue.exists?(id: issue.id)).to eq(false)
end
context 'when updating target column', :aggregate_failures do
let(:target_column) { 'state_id' }
let(:target_value) { 2 }
let(:update_query) do
%{UPDATE "issues" SET "#{target_column}" = #{target_value} WHERE ("issues"."id") IN (SELECT "issues"."id" FROM "issues" WHERE "issues"."project_id" IN (#{issue.project_id}) AND "issues"."#{target_column}" != #{target_value} LIMIT 500)}
end
before do
loose_fk_definition.options[:on_delete] = :update_column_to
loose_fk_definition.options[:target_column] = target_column
loose_fk_definition.options[:target_value] = target_value
end
it 'performs an UPDATE query' do
expect(ApplicationRecord.connection).to receive(:execute).with(update_query).and_call_original
cleaner_service.execute
issue.reload
expect(issue[target_column]).to eq(target_value)
end
context 'when loose_foreign_keys_update_column_to is disabled' do
before do
stub_feature_flags(loose_foreign_keys_update_column_to: false)
end
it 'does not perform UPDATE query' do
allow(ApplicationRecord.connection).to receive(:execute).and_call_original
expect(ApplicationRecord.connection).not_to receive(:execute).with(update_query)
expect(Sidekiq.logger).to receive(:error).with('Invalid on_delete argument: update_column_to')
cleaner_service.execute
end
end
end
end
context 'when composite primary key is used' do

13
spec/support/helpers/value_streams_dashboard_helpers.rb
View File

@ -172,9 +172,9 @@ module ValueStreamsDashboardHelpers
def create_mock_flow_metrics(project)
[
[n_months_ago(1).beginning_of_month + 2.days, 2, 10],
[n_months_ago(2).beginning_of_month + 2.days, 4, 20],
[n_months_ago(3).beginning_of_month + 2.days, 3, 15]
[n_months_ago(1).beginning_of_month + 2.days, 2, 2],
[n_months_ago(2).beginning_of_month + 2.days, 4, 1],
[n_months_ago(3).beginning_of_month + 2.days, 3, 3]
].each do |created_at, lead_time, count|
count.times do
create(
@ -191,13 +191,14 @@ module ValueStreamsDashboardHelpers
def create_mock_merge_request_metrics(project)
[
[n_months_ago(1), 5],
[n_months_ago(2), 7],
[n_months_ago(3), 6]
[n_months_ago(1), 3],
[n_months_ago(2), 1],
[n_months_ago(3), 2]
].each do |merged_at, count|
count.times do
create(
:merge_request,
:skip_diff_creation,
:merged,
created_at: 1.year.ago,
project: project

13
spec/support/shared_examples/features/value_streams_dashboard_shared_examples.rb
View File

@ -59,23 +59,20 @@ end
RSpec.shared_examples 'renders metrics comparison table' do
let(:metric_table) { find_by_testid('panel-dora-chart') }
it 'renders the metrics comparison visualization' do
expect(metric_table).to be_visible
expect(metric_table).to have_content format(_("Metrics comparison for %{title}"), title: panel_title)
end
it "renders the available metrics" do
wait_for_all_requests
expect(metric_table).to be_visible
expect(metric_table).to have_content format(_("Metrics comparison for %{title}"), title: panel_title)
[
['lead-time-for-changes', _('Lead time for changes'), '3.0 d 40.0% 1.0 d 66.7% 0.0 d'],
['time-to-restore-service', _('Time to restore service'), '3.0 d 57.1% 5.0 d 66.7% 0.0 d'],
['lead-time', _('Lead time'), '4.0 d 33.3% 2.0 d 50.0% -'],
['cycle-time', _('Cycle time'), '3.0 d 50.0% 1.0 d 66.7% -'],
['issues', _('Issues created'), '20 33.3% 10 50.0% -'],
['issues-completed', _('Issues closed'), '20 33.3% 10 50.0% -'],
['issues', _('Issues created'), '1 66.7% 2 100.0% -'],
['issues-completed', _('Issues closed'), '1 66.7% 2 100.0% -'],
['deploys', _('Deploys'), '10 25.0% 5 50.0% -'],
['merge-request-throughput', _('Merge request throughput'), '7 16.7% 5 28.6% -'],
['merge-request-throughput', _('Merge request throughput'), '1 50.0% 3 200.0% -'],
['median-time-to-merge', _('Median time to merge'), '- - -'],
['vulnerability-critical', _('Critical vulnerabilities over time'), '5 3 -'],
['vulnerability-high', _('High vulnerabilities over time'), '4 2 -'],

3
spec/support/shared_examples/lib/gitlab/background_migration/backfill_desired_sharding_key_shared_examples.rb
View File

@ -18,6 +18,9 @@ RSpec.shared_examples 'desired sharding key backfill job' do
vulnerability_merge_request_links: {
vulnerabilities: 'https://gitlab.com/gitlab-org/gitlab/-/issues/475058'
},
vulnerability_issue_links: {
vulnerabilities: 'https://gitlab.com/gitlab-org/gitlab/-/issues/475058'
},
vulnerability_finding_evidences: {
vulnerability_occurrences: 'https://gitlab.com/gitlab-org/gitlab/-/issues/480354'
},

112
yarn.lock
View File

@ -2054,76 +2054,76 @@
resolved "https://registry.yarnpkg.com/@rtsao/scc/-/scc-1.1.0.tgz#927dd2fae9bc3361403ac2c7a00c32ddce9ad7e8"
integrity sha512-zt6OdqaDoOnJ1ZYsCYGt9YmWzDXl4vQdKTyJev62gFhRGKdx7mcT54V9KIjg+d2wi9EXsPvAPKe7i7WjfVWB8g==
"@sentry-internal/browser-utils@8.27.0":
version "8.27.0"
resolved "https://registry.yarnpkg.com/@sentry-internal/browser-utils/-/browser-utils-8.27.0.tgz#b8fd1c5e6b8c01d76abbba7ac5017eebcf7d3ed2"
integrity sha512-YTIwQ1GM1NTRXgN4DvpFSQ2x4pjlqQ0FQAyHW5x2ZYv4z7VmqG4Xkid1P/srQUipECk6nxkebfD4WR19nLsvnQ==
"@sentry-internal/browser-utils@8.28.0":
version "8.28.0"
resolved "https://registry.yarnpkg.com/@sentry-internal/browser-utils/-/browser-utils-8.28.0.tgz#bddc58c154e898195d45e971e058e237085bbcc2"
integrity sha512-tE9++KEy8SlqibTmYymuxFVAnutsXBqrwQ936WJbjaMfkqXiro7C1El0ybkprskd0rKS7kln20Q6nQlNlMEoTA==
dependencies:
"@sentry/core" "8.27.0"
"@sentry/types" "8.27.0"
"@sentry/utils" "8.27.0"
"@sentry/core" "8.28.0"
"@sentry/types" "8.28.0"
"@sentry/utils" "8.28.0"
"@sentry-internal/feedback@8.27.0":
version "8.27.0"
resolved "https://registry.yarnpkg.com/@sentry-internal/feedback/-/feedback-8.27.0.tgz#46a4cbde49d7a1cb182792c28341a8c89249e6b1"
integrity sha512-b71PQc9aK1X9b/SO1DiJlrnAEx4n0MzPZQ/tKd9oRWDyGit6pJWZfQns9r2rvc96kJPMOTxFAa/upXRCkA723A==
"@sentry-internal/feedback@8.28.0":
version "8.28.0"
resolved "https://registry.yarnpkg.com/@sentry-internal/feedback/-/feedback-8.28.0.tgz#f278548ead037ad38e54d24b1afcdc1f711c5715"
integrity sha512-5vYunPCDBLCJ8QNnhepacdYheiN+UtYxpGAIaC/zjBC1nDuBgWs+TfKPo1UlO/1sesfgs9ibpxtShOweucL61g==
dependencies:
"@sentry/core" "8.27.0"
"@sentry/types" "8.27.0"
"@sentry/utils" "8.27.0"
"@sentry/core" "8.28.0"
"@sentry/types" "8.28.0"
"@sentry/utils" "8.28.0"
"@sentry-internal/replay-canvas@8.27.0":
version "8.27.0"
resolved "https://registry.yarnpkg.com/@sentry-internal/replay-canvas/-/replay-canvas-8.27.0.tgz#24a154f37b200ed99bb99a39cf98c35f25c2b93b"
integrity sha512-uuEfiWbjwugB9M4KxXxovHYiKRqg/R6U4EF8xM/Ub4laUuEcWsfRp7lQ3MxL3qYojbca8ncIFic2bIoKMPeejA==
"@sentry-internal/replay-canvas@8.28.0":
version "8.28.0"
resolved "https://registry.yarnpkg.com/@sentry-internal/replay-canvas/-/replay-canvas-8.28.0.tgz#6a08541f9fecd912b7334c693a403469c9e34a89"
integrity sha512-RfpYHDHMUKGeEdx41QtHITjEn6P3tGaDPHvatqdrD3yv4j+wbJ6laX1PrIxCpGFUtjdzkqi/KUcvUd2kzbH/FA==
dependencies:
"@sentry-internal/replay" "8.27.0"
"@sentry/core" "8.27.0"
"@sentry/types" "8.27.0"
"@sentry/utils" "8.27.0"
"@sentry-internal/replay" "8.28.0"
"@sentry/core" "8.28.0"
"@sentry/types" "8.28.0"
"@sentry/utils" "8.28.0"
"@sentry-internal/replay@8.27.0":
version "8.27.0"
resolved "https://registry.yarnpkg.com/@sentry-internal/replay/-/replay-8.27.0.tgz#7762647930c3a9b3d99f6d4c486b28f9d3da70c2"
integrity sha512-Ofucncaon98dvlxte2L//hwuG9yILSxNrTz/PmO0k+HzB9q+oBic4667QF+azWR2qv4oKSWpc+vEovP3hVqveA==
"@sentry-internal/replay@8.28.0":
version "8.28.0"
resolved "https://registry.yarnpkg.com/@sentry-internal/replay/-/replay-8.28.0.tgz#a84523066ab363239ef6b4180726908cab510e5f"
integrity sha512-70jvzzOL5O74gahgXKyRkZgiYN93yly5gq+bbj4/6NRQ+EtPd285+ccy0laExdfyK0ugvvwD4v+1MQit52OAsg==
dependencies:
"@sentry-internal/browser-utils" "8.27.0"
"@sentry/core" "8.27.0"
"@sentry/types" "8.27.0"
"@sentry/utils" "8.27.0"
"@sentry-internal/browser-utils" "8.28.0"
"@sentry/core" "8.28.0"
"@sentry/types" "8.28.0"
"@sentry/utils" "8.28.0"
"@sentry/browser@8.27.0":
version "8.27.0"
resolved "https://registry.yarnpkg.com/@sentry/browser/-/browser-8.27.0.tgz#997eb6b3c298a659a109704a0fb660eae365cd3a"
integrity sha512-eL1eaHwoYUGkp4mpeYesH6WtCrm+0u9jYCW5Lm0MAeTmpx22BZKEmj0OljuUJXGnJwFbvPDlRjyz6QG11m8kZA==
"@sentry/browser@8.28.0":
version "8.28.0"
resolved "https://registry.yarnpkg.com/@sentry/browser/-/browser-8.28.0.tgz#e3d28e7a917c212418c887b4fabacc6ed88baea8"
integrity sha512-i/gjMYzIGQiPFH1pCbdnTwH9xs9mTAqzN+goP3GWX5a58frc7h8vxyA/5z0yMd0aCW6U8mVxnoAT72vGbKbx0g==
dependencies:
"@sentry-internal/browser-utils" "8.27.0"
"@sentry-internal/feedback" "8.27.0"
"@sentry-internal/replay" "8.27.0"
"@sentry-internal/replay-canvas" "8.27.0"
"@sentry/core" "8.27.0"
"@sentry/types" "8.27.0"
"@sentry/utils" "8.27.0"
"@sentry-internal/browser-utils" "8.28.0"
"@sentry-internal/feedback" "8.28.0"
"@sentry-internal/replay" "8.28.0"
"@sentry-internal/replay-canvas" "8.28.0"
"@sentry/core" "8.28.0"
"@sentry/types" "8.28.0"
"@sentry/utils" "8.28.0"
"@sentry/core@8.27.0":
version "8.27.0"
resolved "https://registry.yarnpkg.com/@sentry/core/-/core-8.27.0.tgz#a0ebe31cdd9313186a14d9738238ed9cf7a59c01"
integrity sha512-4frlXluHT3Du+Omw91K04jpvbfMtydvg4Bxj2+gt/DT19Swhm/fbEpzdUjgbAd3Jinj/n0qk/jFRXjr9JZKFjg==
"@sentry/core@8.28.0":
version "8.28.0"
resolved "https://registry.yarnpkg.com/@sentry/core/-/core-8.28.0.tgz#dd28fa913c296b443d4070f147c63e81edf429c8"
integrity sha512-+If9uubvpZpvaQQw4HLiKPhrSS9/KcoA/AcdQkNm+5CVwAoOmDPtyYfkPBgfo2hLZnZQqR1bwkz/PrNoOm+gqA==
dependencies:
"@sentry/types" "8.27.0"
"@sentry/utils" "8.27.0"
"@sentry/types" "8.28.0"
"@sentry/utils" "8.28.0"
"@sentry/types@8.27.0":
version "8.27.0"
resolved "https://registry.yarnpkg.com/@sentry/types/-/types-8.27.0.tgz#a5c7d2877c6c3620f812b2b31377b58d390b89d4"
integrity sha512-B6lrP46+m2x0lfqWc9F4VcUbN893mVGnPEd7KIMRk95mPzkFJ3sNxggTQF5/ZfNO7lDQYQb22uysB5sj/BqFiw==
"@sentry/types@8.28.0":
version "8.28.0"
resolved "https://registry.yarnpkg.com/@sentry/types/-/types-8.28.0.tgz#a1cfc004d5714679cb3fed06c27298b0275d13b5"
integrity sha512-hOfqfd92/AzBrEdMgmmV1VfOXJbIfleFTnerRl0mg/+CcNgP/6+Fdonp354TD56ouWNF2WkOM6sEKSXMWp6SEQ==
"@sentry/utils@8.27.0":
version "8.27.0"
resolved "https://registry.yarnpkg.com/@sentry/utils/-/utils-8.27.0.tgz#308f6cc34acac175c500e4dd5b5007cdb621c79e"
integrity sha512-gyJM3SyLQe0A3mkQVVNdKYvk3ZoikkYgyA/D+5StFNLKdyUgEbJgXOGXrQSSYPF7BSX6Sc5b0KHCglPII0KuKw==
"@sentry/utils@8.28.0":
version "8.28.0"
resolved "https://registry.yarnpkg.com/@sentry/utils/-/utils-8.28.0.tgz#0feb46015033879b2a3cee4c0661386610025f47"
integrity sha512-smhk7PJpvDMQ2DB5p2qn9UeoUHdU41IgjMmS2xklZpa8tjzBTxDeWpGvrX2fuH67D9bAJuLC/XyZjJCHLoEW5g==
dependencies:
"@sentry/types" "8.27.0"
"@sentry/types" "8.28.0"
"@sinclair/typebox@^0.27.8":
version "0.27.8"