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

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2023-12-12 18:07:46 +00:00
parent 86a3b1b3ae
commit 6121ad5af3
159 changed files with 1084 additions and 850 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
.gitlab/CODEOWNERS
View File

@ -509,8 +509,6 @@ lib/gitlab/checks/**
/doc/administration/monitoring/performance/ @jglassman1
/doc/administration/monitoring/prometheus/gitlab_exporter.md @jglassman1
/doc/administration/monitoring/prometheus/index.md @axil
/doc/administration/monitoring/prometheus/pgbouncer_exporter.md @aqualls
/doc/administration/monitoring/prometheus/postgres_exporter.md @aqualls
/doc/administration/monitoring/prometheus/registry_exporter.md @phillipwells
/doc/administration/monitoring/prometheus/web_exporter.md @jglassman1
/doc/administration/nfs.md @axil
@ -523,8 +521,7 @@ lib/gitlab/checks/**
/doc/administration/packages/ @marcel.amirault
/doc/administration/packages/index.md @phillipwells
/doc/administration/polling.md @axil
/doc/administration/postgresql/ @aqualls
/doc/administration/postgresql/multiple_databases.md @lciutacu
/doc/administration/postgresql/ @lciutacu
/doc/administration/raketasks/ @axil
/doc/administration/raketasks/ldap.md @jglassman1
/doc/administration/raketasks/praefect.md @eread
@ -552,6 +549,7 @@ lib/gitlab/checks/**
/doc/administration/settings/import_export_rate_limits.md @eread @ashrafkhamis
/doc/administration/settings/instance_template_repository.md @msedlakjakubowski
/doc/administration/settings/jira_cloud_app.md @eread @ashrafkhamis
/doc/administration/settings/jira_cloud_app_troubleshooting.md @eread @ashrafkhamis
/doc/administration/settings/package_registry_rate_limits.md @phillipwells
/doc/administration/settings/project_integration_management.md @eread @ashrafkhamis
/doc/administration/settings/push_event_activities_limit.md @msedlakjakubowski
@ -563,6 +561,7 @@ lib/gitlab/checks/**
/doc/administration/settings/rate_limits_on_git_ssh_operations.md @msedlakjakubowski
/doc/administration/settings/scim_setup.md @jglassman1
/doc/administration/settings/security_and_compliance.md @rdickenson
/doc/administration/settings/security_contact_information.md @eread
/doc/administration/settings/slack_app.md @eread @ashrafkhamis
/doc/administration/settings/terraform_limits.md @phillipwells
/doc/administration/settings/third_party_offers.md @lciutacu
@ -577,7 +576,6 @@ lib/gitlab/checks/**
/doc/administration/terraform_state.md @phillipwells
/doc/administration/timezone.md @axil
/doc/administration/troubleshooting/ @axil
/doc/administration/troubleshooting/postgresql.md @aqualls
/doc/administration/uploads.md @axil
/doc/administration/user_settings.md @jglassman1
/doc/api/access_requests.md @jglassman1
@ -595,7 +593,6 @@ lib/gitlab/checks/**
/doc/api/commits.md @msedlakjakubowski
/doc/api/container_registry.md @marcel.amirault
/doc/api/custom_attributes.md @msedlakjakubowski
/doc/api/database_migrations.md @aqualls
/doc/api/dependencies.md @rdickenson
/doc/api/dependency_list_export.md @rdickenson
/doc/api/dependency_proxy.md @marcel.amirault
@ -740,8 +737,6 @@ lib/gitlab/checks/**
/doc/api/vulnerability_findings.md @rdickenson
/doc/architecture/blueprints/cells/ @lciutacu
/doc/architecture/blueprints/ci_builds_runner_fleet_metrics/ @fneill
/doc/architecture/blueprints/database/scalability/patterns/ @aqualls
/doc/architecture/blueprints/database_scaling/ @aqualls
/doc/architecture/blueprints/google_artifact_registry_integration/ @marcel.amirault
/doc/architecture/blueprints/organization/ @lciutacu
/doc/ci/ @marcel.amirault @lyspin
@ -806,7 +801,6 @@ lib/gitlab/checks/**
/doc/editor_extensions/ @aqualls
/doc/gitlab-basics/ @msedlakjakubowski
/doc/install/ @axil
/doc/install/postgresql_extensions.md @aqualls
/doc/integration/ @jglassman1
/doc/integration/advanced_search/ @ashrafkhamis
/doc/integration/akismet.md @phillipwells
@ -860,7 +854,6 @@ lib/gitlab/checks/**
/doc/tutorials/update_commit_messages/ @msedlakjakubowski
/doc/tutorials/website_project_with_analytics/ @lciutacu
/doc/update/ @axil
/doc/update/background_migrations.md @aqualls
/doc/user/ai_features.md @sselhorn
/doc/user/analytics/ @lciutacu
/doc/user/analytics/ci_cd_analytics.md @phillipwells
@ -875,13 +868,19 @@ lib/gitlab/checks/**
/doc/user/emoji_reactions.md @msedlakjakubowski
/doc/user/enterprise_user/ @jglassman1
/doc/user/gitlab_duo_chat.md @sselhorn
/doc/user/group/ @lciutacu
/doc/user/group/access_and_permissions.md @lciutacu
/doc/user/group/clusters/ @phillipwells
/doc/user/group/compliance_frameworks.md @eread
/doc/user/group/contribution_analytics/ @lciutacu
/doc/user/group/custom_project_templates.md @msedlakjakubowski
/doc/user/group/devops_adoption/ @lciutacu
/doc/user/group/epics/ @msedlakjakubowski
/doc/user/group/import/ @eread @ashrafkhamis
/doc/user/group/index.md @lciutacu
/doc/user/group/insights/ @lciutacu
/doc/user/group/issues_analytics/ @lciutacu
/doc/user/group/iterations/ @msedlakjakubowski
/doc/user/group/manage.md @lciutacu
/doc/user/group/moderate_users.md @phillipwells
/doc/user/group/planning_hierarchy/ @msedlakjakubowski
/doc/user/group/reporting/ @phillipwells
@ -889,6 +888,10 @@ lib/gitlab/checks/**
/doc/user/group/roadmap/ @msedlakjakubowski
/doc/user/group/saml_sso/ @jglassman1
/doc/user/group/settings/ @jglassman1
/doc/user/group/ssh_certificates.md @msedlakjakubowski
/doc/user/group/subgroups/ @lciutacu
/doc/user/group/troubleshooting.md @lciutacu
/doc/user/group/value_stream_analytics/ @lciutacu
/doc/user/infrastructure/ @phillipwells
/doc/user/infrastructure/clusters/manage/management_project_applications/ @phillipwells
/doc/user/infrastructure/clusters/manage/management_project_applications/runner.md @fneill
@ -944,8 +947,10 @@ lib/gitlab/checks/**
/doc/user/project/repository/web_editor.md @ashrafkhamis
/doc/user/project/settings/import_export.md @eread @ashrafkhamis
/doc/user/project/settings/import_export_troubleshooting.md @eread @ashrafkhamis
/doc/user/project/settings/index.md @lciutacu
/doc/user/project/settings/migrate_projects.md @lciutacu
/doc/user/project/settings/project_access_tokens.md @jglassman1
/doc/user/project/settings/project_features_permissions.md @lciutacu
/doc/user/project/use_project_as_go_package.md @lciutacu
/doc/user/project/web_ide/ @ashrafkhamis
/doc/user/project/working_with_projects.md @lciutacu
/doc/user/public_access.md @lciutacu

5
.gitlab/ci/release-environments.gitlab-ci.yml
View File

@ -20,4 +20,7 @@ start-release-environments-pipeline:
PARENT_PIPELINE_ID: $CI_PIPELINE_ID
trigger:
strategy: depend
include: .gitlab/ci/release-environments/main.gitlab-ci.yml
include:
- project: 'gitlab-org/gitlab'
ref: 'master'
file: '.gitlab/ci/release-environments/main.gitlab-ci.yml'

1
.rubocop_todo/rspec/context_wording.yml
View File

@ -2960,7 +2960,6 @@ RSpec/ContextWording:
- 'spec/tasks/gitlab/packages/migrate_rake_spec.rb'
- 'spec/tasks/gitlab/terraform/migrate_rake_spec.rb'
- 'spec/tasks/gitlab/workhorse_rake_spec.rb'
- 'spec/tooling/danger/project_helper_spec.rb'
- 'spec/tooling/lib/tooling/parallel_rspec_runner_spec.rb'
- 'spec/uploaders/attachment_uploader_spec.rb'
- 'spec/uploaders/avatar_uploader_spec.rb'

1
.rubocop_todo/rspec/feature_category.yml
View File

@ -5285,7 +5285,6 @@ RSpec/FeatureCategory:
- 'spec/tooling/danger/datateam_spec.rb'
- 'spec/tooling/danger/feature_flag_spec.rb'
- 'spec/tooling/danger/analytics_instrumentation_spec.rb'
- 'spec/tooling/danger/project_helper_spec.rb'
- 'spec/tooling/danger/sidekiq_queues_spec.rb'
- 'spec/tooling/docs/deprecation_handling_spec.rb'
- 'spec/tooling/graphql/docs/renderer_spec.rb'

254
app/assets/javascripts/content_editor/components/formatting_toolbar.vue
View File

@ -75,137 +75,137 @@ export default {
</script>
<template>
<div
class="gl-w-full gl-display-flex gl-align-items-center gl-flex-wrap gl-border-b gl-border-gray-100 gl-px-3 gl-rounded-top-base gl-justify-content-space-between"
class="gl-w-full gl-py-3 gl-row-gap-2 gl-display-flex gl-align-items-center gl-flex-wrap gl-border-b gl-border-gray-100 gl-px-3 gl-rounded-top-base"
data-testid="formatting-toolbar"
>
<div class="gl-py-3 gl-w-full gl-display-flex gl-align-items-flex-start">
<div class="gl-display-flex">
<toolbar-text-style-dropdown
data-testid="text-styles"
@execute="trackToolbarControlExecution"
/>
<header-divider />
</div>
<div v-if="codeSuggestionsEnabled" class="gl-display-flex">
<toolbar-button
v-if="codeSuggestionsEnabled"
data-testid="code-suggestion"
content-type="codeSuggestion"
icon-name="doc-code"
editor-command="insertCodeSuggestion"
:label="__('Insert suggestion')"
:show-active-state="false"
@execute="trackToolbarControlExecution"
/>
<header-divider />
</div>
<toolbar-button
data-testid="bold"
content-type="bold"
icon-name="bold"
editor-command="toggleBold"
:label="i18n.bold"
<div class="gl-display-flex">
<toolbar-text-style-dropdown
data-testid="text-styles"
@execute="trackToolbarControlExecution"
/>
<toolbar-button
data-testid="italic"
content-type="italic"
icon-name="italic"
editor-command="toggleItalic"
:label="i18n.italic"
@execute="trackToolbarControlExecution"
/>
<div class="gl-display-flex">
<toolbar-button
data-testid="strike"
content-type="strike"
icon-name="strikethrough"
editor-command="toggleStrike"
:label="i18n.strike"
@execute="trackToolbarControlExecution"
/>
<header-divider />
</div>
<toolbar-button
data-testid="blockquote"
content-type="blockquote"
icon-name="quote"
editor-command="toggleBlockquote"
:label="i18n.quote"
@execute="trackToolbarControlExecution"
/>
<toolbar-button
data-testid="code"
content-type="code"
icon-name="code"
editor-command="toggleCode"
:label="i18n.code"
@execute="trackToolbarControlExecution"
/>
<toolbar-button
data-testid="link"
content-type="link"
icon-name="link"
editor-command="editLink"
:label="i18n.link"
@execute="trackToolbarControlExecution"
/>
<toolbar-button
data-testid="bullet-list"
content-type="bulletList"
icon-name="list-bulleted"
class="gl-display-none gl-sm-display-inline"
editor-command="toggleBulletList"
:label="i18n.bulletList"
@execute="trackToolbarControlExecution"
/>
<toolbar-button
data-testid="ordered-list"
content-type="orderedList"
icon-name="list-numbered"
class="gl-display-none gl-sm-display-inline"
editor-command="toggleOrderedList"
:label="i18n.numberedList"
@execute="trackToolbarControlExecution"
/>
<div class="gl-display-flex">
<toolbar-button
data-testid="task-list"
content-type="taskList"
icon-name="list-task"
class="gl-display-none gl-sm-display-inline"
editor-command="toggleTaskList"
:label="i18n.taskList"
@execute="trackToolbarControlExecution"
/>
<header-divider />
</div>
<toolbar-table-button data-testid="table" @execute="trackToolbarControlExecution" />
<div class="gl-display-flex">
<toolbar-attachment-button
v-if="!hideAttachmentButton"
data-testid="attachment"
@execute="trackToolbarControlExecution"
/>
<!-- TODO Add icon and trigger functionality from here -->
<toolbar-button
v-if="supportsQuickActions"
data-testid="quick-actions"
content-type="quickAction"
icon-name="quick-actions"
class="gl-display-none gl-sm-display-inline"
editor-command="insertQuickAction"
:label="__('Add a quick action')"
@execute="trackToolbarControlExecution"
/>
<header-divider v-if="newCommentTemplatePath" />
</div>
<comment-templates-dropdown
v-if="newCommentTemplatePath"
:new-comment-template-path="newCommentTemplatePath"
@select="insertSavedReply"
/>
<toolbar-more-dropdown data-testid="more" @execute="trackToolbarControlExecution" />
<header-divider />
</div>
<div v-if="codeSuggestionsEnabled" class="gl-display-flex">
<toolbar-button
v-if="codeSuggestionsEnabled"
data-testid="code-suggestion"
content-type="codeSuggestion"
icon-name="doc-code"
editor-command="insertCodeSuggestion"
:label="__('Insert suggestion')"
:show-active-state="false"
@execute="trackToolbarControlExecution"
/>
<header-divider />
</div>
<toolbar-button
data-testid="bold"
content-type="bold"
icon-name="bold"
editor-command="toggleBold"
:label="i18n.bold"
@execute="trackToolbarControlExecution"
/>
<toolbar-button
data-testid="italic"
content-type="italic"
icon-name="italic"
editor-command="toggleItalic"
:label="i18n.italic"
@execute="trackToolbarControlExecution"
/>
<div class="gl-display-flex">
<toolbar-button
data-testid="strike"
content-type="strike"
icon-name="strikethrough"
editor-command="toggleStrike"
:label="i18n.strike"
@execute="trackToolbarControlExecution"
/>
<header-divider />
</div>
<toolbar-button
data-testid="blockquote"
content-type="blockquote"
icon-name="quote"
editor-command="toggleBlockquote"
:label="i18n.quote"
@execute="trackToolbarControlExecution"
/>
<toolbar-button
data-testid="code"
content-type="code"
icon-name="code"
editor-command="toggleCode"
:label="i18n.code"
@execute="trackToolbarControlExecution"
/>
<toolbar-button
data-testid="link"
content-type="link"
icon-name="link"
editor-command="editLink"
:label="i18n.link"
@execute="trackToolbarControlExecution"
/>
<toolbar-button
data-testid="bullet-list"
content-type="bulletList"
icon-name="list-bulleted"
class="gl-display-none gl-sm-display-inline"
editor-command="toggleBulletList"
:label="i18n.bulletList"
@execute="trackToolbarControlExecution"
/>
<toolbar-button
data-testid="ordered-list"
content-type="orderedList"
icon-name="list-numbered"
class="gl-display-none gl-sm-display-inline"
editor-command="toggleOrderedList"
:label="i18n.numberedList"
@execute="trackToolbarControlExecution"
/>
<div class="gl-display-flex">
<toolbar-button
data-testid="task-list"
content-type="taskList"
icon-name="list-task"
class="gl-display-none gl-sm-display-inline"
editor-command="toggleTaskList"
:label="i18n.taskList"
@execute="trackToolbarControlExecution"
/>
<div class="gl-display-none gl-sm-display-flex">
<header-divider />
</div>
</div>
<toolbar-table-button data-testid="table" @execute="trackToolbarControlExecution" />
<div class="gl-display-flex">
<toolbar-attachment-button
v-if="!hideAttachmentButton"
data-testid="attachment"
@execute="trackToolbarControlExecution"
/>
<!-- TODO Add icon and trigger functionality from here -->
<toolbar-button
v-if="supportsQuickActions"
data-testid="quick-actions"
content-type="quickAction"
icon-name="quick-actions"
class="gl-display-none gl-sm-display-inline"
editor-command="insertQuickAction"
:label="__('Add a quick action')"
@execute="trackToolbarControlExecution"
/>
<header-divider v-if="newCommentTemplatePath" />
</div>
<comment-templates-dropdown
v-if="newCommentTemplatePath"
:new-comment-template-path="newCommentTemplatePath"
@select="insertSavedReply"
/>
<toolbar-more-dropdown data-testid="more" @execute="trackToolbarControlExecution" />
</div>
</template>

2
app/assets/javascripts/emoji/components/category.vue
View File

@ -52,7 +52,7 @@ export default {
:key="index"
:emojis="emojiGroup"
:render-group="renderGroup"
:click-emoji="(emoji) => onClick(emoji)"
@emoji-click="onClick"
/>
</template>
<p v-else>

37
app/assets/javascripts/emoji/components/emoji_group.vue
View File

@ -1,10 +1,10 @@
<script>
import { compatFunctionalMixin } from '~/lib/utils/vue3compat/compat_functional_mixin';
import { GlButton } from '@gitlab/ui';
export default {
// Temporary mixin for migration from Vue.js 2 to @vue/compat
mixins: [compatFunctionalMixin],
components: {
GlButton,
},
props: {
emojis: {
type: Array,
@ -14,28 +14,33 @@ export default {
type: Boolean,
required: true,
},
clickEmoji: {
type: Function,
required: true,
},
methods: {
clickEmoji(emoji) {
this.$emit('emoji-click', emoji);
},
},
};
</script>
<!-- eslint-disable-next-line vue/no-deprecated-functional-template -->
<template functional>
<template>
<div class="gl-display-flex gl-flex-wrap gl-mb-2">
<template v-if="props.renderGroup">
<button
v-for="emoji in props.emojis"
<template v-if="renderGroup">
<gl-button
v-for="emoji in emojis"
:key="emoji"
type="button"
class="gl-border-0 gl-bg-transparent gl-px-0 gl-py-2 gl-text-center emoji-picker-emoji"
category="tertiary"
class="emoji-picker-emoji"
:aria-label="emoji"
data-testid="emoji-button"
@click="props.clickEmoji(emoji)"
button-text-classes="gl-display-none!"
@click="clickEmoji(emoji)"
>
<gl-emoji :data-name="emoji" />
</button>
<template #emoji>
<gl-emoji :data-name="emoji" class="gl-mr-0!" />
</template>
</gl-button>
</template>
</div>
</template>

25
app/assets/javascripts/organizations/mock_data.js
View File

@ -302,13 +302,26 @@ export const organizationCreateResponseWithErrors = {
},
};
export const updateOrganizationResponse = {
organization: {
id: 'gid://gitlab/Organizations/1',
name: 'Default updated',
webUrl: 'http://127.0.0.1:3000/-/organizations/default',
export const organizationUpdateResponse = {
data: {
organizationUpdate: {
organization: {
id: 'gid://gitlab/Organizations::Organization/1',
name: 'Default updated',
webUrl: 'http://127.0.0.1:3000/-/organizations/default',
},
errors: [],
},
},
};
export const organizationUpdateResponseWithErrors = {
data: {
organizationUpdate: {
organization: null,
errors: ['Path is too short (minimum is 2 characters)'],
},
},
errors: [],
};
export const pageInfo = {

105
app/assets/javascripts/organizations/settings/general/components/change_url.vue
View File

@ -5,11 +5,14 @@ import { visitUrlWithAlerts, joinPaths } from '~/lib/utils/url_utility';
import { createAlert } from '~/alert';
import OrganizationUrlField from '~/organizations/shared/components/organization_url_field.vue';
import { FORM_FIELD_PATH, FORM_FIELD_PATH_VALIDATORS } from '~/organizations/shared/constants';
import updateOrganizationMutation from '../graphql/mutations/update_organization.mutation.graphql';
import { convertToGraphQLId } from '~/graphql_shared/utils';
import { TYPE_ORGANIZATION } from '~/graphql_shared/constants';
import FormErrorsAlert from '~/vue_shared/components/form/errors_alert.vue';
import organizationUpdateMutation from '../graphql/mutations/organization_update.mutation.graphql';
export default {
name: 'OrganizationSettings',
components: { OrganizationUrlField, GlFormFields, GlButton, GlForm, GlCard },
components: { OrganizationUrlField, GlFormFields, GlButton, GlForm, GlCard, FormErrorsAlert },
inject: ['organization'],
i18n: {
cardHeaderTitle: s__('Organization|Change organization URL'),
@ -39,6 +42,7 @@ export default {
path: this.organization.path,
},
loading: false,
errors: [],
};
},
computed: {
@ -47,23 +51,27 @@ export default {
},
},
methods: {
async onSubmit(formValues) {
async onSubmit() {
this.errors = [];
this.loading = true;
try {
const {
data: {
updateOrganization: { errors, organization },
organizationUpdate: { errors, organization },
},
} = await this.$apollo.mutate({
mutation: updateOrganizationMutation,
mutation: organizationUpdateMutation,
variables: {
id: this.organization.id,
path: formValues.path,
input: {
id: convertToGraphQLId(TYPE_ORGANIZATION, this.organization.id),
path: this.formValues.path,
},
},
});
if (errors.length) {
// TODO: handle errors when using real API after https://gitlab.com/gitlab-org/gitlab/-/issues/419608 is complete.
this.errors = errors;
return;
}
@ -85,44 +93,47 @@ export default {
</script>
<template>
<gl-card
class="gl-new-card"
header-class="gl-new-card-header gl-flex-direction-column"
body-class="gl-new-card-body gl-px-5 gl-py-4"
>
<template #header>
<div class="gl-new-card-title-wrapper">
<h4 class="gl-new-card-title">{{ $options.i18n.cardHeaderTitle }}</h4>
</div>
<p class="gl-new-card-description">{{ $options.i18n.cardHeaderDescription }}</p>
</template>
<gl-form :id="$options.formId">
<gl-form-fields
v-model="formValues"
:form-id="$options.formId"
:fields="$options.fields"
@submit="onSubmit"
>
<template #input(path)="{ id, value, validation, input, blur }">
<organization-url-field
:id="id"
:value="value"
:validation="validation"
@input="input"
@blur="blur"
/>
</template>
</gl-form-fields>
<div class="gl-display-flex gl-gap-3">
<gl-button
type="submit"
variant="danger"
class="js-no-auto-disable"
:loading="loading"
:disabled="isSubmitButtonDisabled"
>{{ $options.i18n.submitButtonText }}</gl-button
<div>
<form-errors-alert v-model="errors" />
<gl-card
class="gl-new-card"
header-class="gl-new-card-header gl-flex-direction-column"
body-class="gl-new-card-body gl-px-5 gl-py-4"
>
<template #header>
<div class="gl-new-card-title-wrapper">
<h4 class="gl-new-card-title">{{ $options.i18n.cardHeaderTitle }}</h4>
</div>
<p class="gl-new-card-description">{{ $options.i18n.cardHeaderDescription }}</p>
</template>
<gl-form :id="$options.formId">
<gl-form-fields
v-model="formValues"
:form-id="$options.formId"
:fields="$options.fields"
@submit="onSubmit"
>
</div>
</gl-form>
</gl-card>
<template #input(path)="{ id, value, validation, input, blur }">
<organization-url-field
:id="id"
:value="value"
:validation="validation"
@input="input"
@blur="blur"
/>
</template>
</gl-form-fields>
<div class="gl-display-flex gl-gap-3">
<gl-button
type="submit"
variant="danger"
class="js-no-auto-disable"
:loading="loading"
:disabled="isSubmitButtonDisabled"
>{{ $options.i18n.submitButtonText }}</gl-button
>
</div>
</gl-form>
</gl-card>
</div>
</template>

34
app/assets/javascripts/organizations/settings/general/components/organization_settings.vue
View File

@ -1,14 +1,18 @@
<script>
import { s__, __ } from '~/locale';
import { createAlert, VARIANT_INFO } from '~/alert';
import { createAlert } from '~/alert';
import { visitUrlWithAlerts } from '~/lib/utils/url_utility';
import NewEditForm from '~/organizations/shared/components/new_edit_form.vue';
import { FORM_FIELD_NAME, FORM_FIELD_ID } from '~/organizations/shared/constants';
import SettingsBlock from '~/vue_shared/components/settings/settings_block.vue';
import updateOrganizationMutation from '../graphql/mutations/update_organization.mutation.graphql';
import { convertToGraphQLId } from '~/graphql_shared/utils';
import { TYPE_ORGANIZATION } from '~/graphql_shared/constants';
import FormErrorsAlert from '~/vue_shared/components/form/errors_alert.vue';
import organizationUpdateMutation from '../graphql/mutations/organization_update.mutation.graphql';
export default {
name: 'OrganizationSettings',
components: { NewEditForm, SettingsBlock },
components: { NewEditForm, SettingsBlock, FormErrorsAlert },
inject: ['organization'],
i18n: {
submitButtonText: __('Save changes'),
@ -25,30 +29,41 @@ export default {
data() {
return {
loading: false,
errors: [],
};
},
methods: {
async onSubmit(formValues) {
this.errors = [];
this.loading = true;
try {
const {
data: {
updateOrganization: { errors },
organizationUpdate: { errors },
},
} = await this.$apollo.mutate({
mutation: updateOrganizationMutation,
mutation: organizationUpdateMutation,
variables: {
id: this.organization.id,
name: formValues.name,
input: {
id: convertToGraphQLId(TYPE_ORGANIZATION, this.organization.id),
name: formValues.name,
},
},
});
if (errors.length) {
// TODO: handle errors when using real API after https://gitlab.com/gitlab-org/gitlab/-/issues/419608 is complete.
this.errors = errors;
return;
}
createAlert({ message: this.$options.i18n.successMessage, variant: VARIANT_INFO });
visitUrlWithAlerts(window.location.href, [
{
id: 'organization-successfully-updated',
message: this.$options.i18n.successMessage,
variant: 'info',
},
]);
} catch (error) {
createAlert({ message: this.$options.i18n.errorMessage, error, captureError: true });
} finally {
@ -64,6 +79,7 @@ export default {
<template #title>{{ $options.i18n.settingsBlock.title }}</template>
<template #description>{{ $options.i18n.settingsBlock.description }}</template>
<template #default>
<form-errors-alert v-model="errors" />
<new-edit-form
:loading="loading"
:initial-form-values="organization"

10
app/assets/javascripts/organizations/settings/general/graphql/mutations/organization_update.mutation.graphql Normal file
View File

@ -0,0 +1,10 @@
mutation organizationUpdate($input: OrganizationUpdateInput!) {
organizationUpdate(input: $input) {
organization {
id
name
webUrl
}
errors
}
}

10
app/assets/javascripts/organizations/settings/general/graphql/mutations/update_organization.mutation.graphql
View File

@ -1,10 +0,0 @@
mutation updateOrganization($input: LocalUpdateOrganizationInput!) {
updateOrganization(input: $input) @client {
organization {
id
name
webUrl
}
errors
}
}

5
app/assets/javascripts/organizations/settings/general/graphql/typedefs.graphql
View File

@ -1,5 +0,0 @@
# TODO: Use real input type when https://gitlab.com/gitlab-org/gitlab/-/issues/419608 is complete.
input LocalUpdateOrganizationInput {
id: ID!
name: String
}

3
app/assets/javascripts/organizations/settings/general/index.js
View File

@ -3,7 +3,6 @@ import VueApollo from 'vue-apollo';
import { convertObjectPropsToCamelCase } from '~/lib/utils/common_utils';
import createDefaultClient from '~/lib/graphql';
import resolvers from '../../shared/graphql/resolvers';
import App from './components/app.vue';
export const initOrganizationsSettingsGeneral = () => {
@ -19,7 +18,7 @@ export const initOrganizationsSettingsGeneral = () => {
);
const apolloProvider = new VueApollo({
defaultClient: createDefaultClient(resolvers),
defaultClient: createDefaultClient(),
});
return new Vue({

15
app/assets/javascripts/organizations/shared/graphql/resolvers.js
View File

@ -1,9 +1,4 @@
import {
organizations,
organizationProjects,
organizationGroups,
updateOrganizationResponse,
} from '../../mock_data';
import { organizations, organizationProjects, organizationGroups } from '../../mock_data';
const simulateLoading = () => {
return new Promise((resolve) => {
@ -24,12 +19,4 @@ export default {
};
},
},
Mutation: {
updateOrganization: async () => {
// Simulate API loading
await simulateLoading();
return updateOrganizationResponse;
},
},
};

3
app/assets/javascripts/pages/projects/shared/web_ide_link/index.js
View File

@ -18,7 +18,7 @@ export default ({ el, router }) => {
const { projectPath, ref, isBlob, webIdeUrl, ...options } = convertObjectPropsToCamelCase(
JSON.parse(el.dataset.options),
);
const { webIdePromoPopoverImg } = el.dataset;
const { webIdePromoPopoverImg, cssClasses } = el.dataset;
// eslint-disable-next-line no-new
new Vue({
@ -40,6 +40,7 @@ export default ({ el, router }) => {
joinPaths('/', projectPath, 'edit', ref, '-', this.$route?.params.path || '', '/'),
),
projectPath,
cssClasses,
...options,
},
});

10
app/assets/javascripts/releases/components/app_edit_new.vue
View File

@ -197,12 +197,16 @@ export default {
:extra-links="milestoneComboboxExtraLinks"
/>
</gl-form-group>
<gl-form-group :label="__('Release date')" label-for="release-released-at">
<template #label-description>
<gl-form-group
:label="__('Release date')"
:label-description="__('The date when the release is ready.')"
label-for="release-released-at"
>
<template #description>
<gl-sprintf
:message="
__(
'The date when the release is ready. A release with a date in the future is labeled as an %{linkStart}Upcoming Release%{linkEnd}.',
'A release with a date in the future is labeled as an %{linkStart}Upcoming Release%{linkEnd}.',
)
"
>

7
app/assets/javascripts/vue_shared/components/web_ide_link.vue
View File

@ -145,6 +145,11 @@ export default {
required: false,
default: '',
},
cssClasses: {
type: String,
required: false,
default: 'gl-sm-ml-3',
},
},
data() {
return {
@ -329,7 +334,7 @@ export default {
</script>
<template>
<div class="gl-sm-ml-3">
<div :class="cssClasses">
<gl-disclosure-dropdown
v-if="hasActions"
:variant="isBlob ? 'confirm' : 'default'"

10
app/assets/stylesheets/framework/emojis.scss
View File

@ -41,6 +41,16 @@ gl-emoji {
&:focus {
transform: scale(1.3);
}
&:focus {
@include gl-z-index-2;
mix-blend-mode: normal !important;
}
gl-emoji {
width: px-to-rem($gl-padding);
top: -1px;
}
}
.emoji-picker .gl-dropdown .dropdown-menu {

33
app/graphql/resolvers/group_milestones_resolver.rb
View File

@ -2,6 +2,8 @@
module Resolvers
class GroupMilestonesResolver < MilestonesResolver
include ::API::Concerns::Milestones::GroupProjectParams
argument :include_ancestors, GraphQL::Types::Boolean,
required: false,
description: 'Include milestones from all parent groups.'
@ -14,36 +16,7 @@ module Resolvers
private
def parent_id_parameters(args)
include_ancestors = args[:include_ancestors].present?
include_descendants = args[:include_descendants].present?
return { group_ids: parent.id } unless include_ancestors || include_descendants
group_ids = if include_ancestors && include_descendants
parent.self_and_hierarchy
elsif include_ancestors
parent.self_and_ancestors
else
parent.self_and_descendants
end
project_ids = if include_descendants
group_projects.with_issues_or_mrs_available_for_user(current_user)
else
nil
end
{
group_ids: group_ids.public_or_visible_to_user(current_user).select(:id),
project_ids: project_ids
}
end
def group_projects
GroupProjectsFinder.new(
group: parent,
current_user: current_user,
options: { include_subgroups: true }
).execute
group_finder_params(parent, args)
end
def preloads

9
app/graphql/resolvers/project_milestones_resolver.rb
View File

@ -2,6 +2,8 @@
module Resolvers
class ProjectMilestonesResolver < MilestonesResolver
include ::API::Concerns::Milestones::GroupProjectParams
argument :include_ancestors, GraphQL::Types::Boolean,
required: false,
description: "Also return milestones in the project's parent group and its ancestors."
@ -11,12 +13,7 @@ module Resolvers
private
def parent_id_parameters(args)
return { project_ids: parent.id } unless args[:include_ancestors].present? && parent.group.present?
{
group_ids: parent.group.self_and_ancestors.select(:id),
project_ids: parent.id
}
project_finder_params(parent, args)
end
end
end

17
app/services/ml/find_or_create_model_version_service.rb
View File

@ -8,21 +8,20 @@ module Ml
@version = params[:version]
@package = params[:package]
@description = params[:description]
@user = params[:user]
@params = params
end
def execute
model = Ml::FindOrCreateModelService.new(@project, @name).execute
model_version = Ml::ModelVersion.by_project_id_name_and_version(@project.id, @name, @version)
model_version = Ml::ModelVersion.find_or_create!(model, @version, @package, @description)
return model_version if model_version
unless model_version.candidate
model_version.candidate = ::Ml::CreateCandidateService.new(
model.default_experiment,
{ model_version: model_version }
).execute
end
model = Ml::Model.by_project_id_and_name(@project.id, @name)
model_version
return unless model
Ml::CreateModelVersionService.new(model, @params).execute
end
end
end

38
app/services/packages/ml_model/create_package_file_service.rb
View File

@ -4,47 +4,27 @@ module Packages
module MlModel
class CreatePackageFileService < BaseService
def execute
::Packages::Package.transaction do
package = find_or_create_package
find_or_create_model_version(package)
@package = params[:model_version]&.package
create_package_file(package)
return unless @package
::Packages::Package.transaction do
update_package
create_package_file
end
end
private
def find_or_create_package
package_params = {
name: params[:package_name],
version: params[:package_version],
build: params[:build],
status: params[:status]
}
package = ::Packages::MlModel::FindOrCreatePackageService
.new(project, current_user, package_params)
.execute
attr_reader :package
def update_package
package.update_column(:status, params[:status]) if params[:status] && params[:status] != package.status
package.create_build_infos!(params[:build])
package
end
def find_or_create_model_version(package)
model_version_params = {
model_name: package.name,
version: package.version,
package: package,
user: current_user
}
Ml::FindOrCreateModelVersionService.new(project, model_version_params).execute
end
def create_package_file(package)
def create_package_file
file_params = {
file: params[:file],
size: params[:file].size,

8
app/views/projects/tree/_tree_header.html.haml
View File

@ -8,18 +8,18 @@
#js-blob-controls
.tree-controls
.d-block.d-sm-flex.flex-wrap.align-items-start.gl-children-ml-sm-3.gl-first-child-ml-sm-0<
.gl-display-flex.gl-flex-wrap.gl-gap-3.gl-mb-3.gl-sm-mb-0
= render_if_exists 'projects/tree/lock_link'
= render 'projects/buttons/compare', project: @project, ref: @ref, root_ref: @repository&.root_ref
#js-tree-history-link{ data: { history_link: project_commits_path(@project, @ref) } }
= render 'projects/find_file_link'
= render 'shared/web_ide_button', blob: nil
= render 'shared/web_ide_button', blob: nil, css_classes: 'gl-w-full gl-sm-w-auto'
.project-code-holder.d-none.d-sm-inline-block>
.project-code-holder.d-none.d-sm-inline-block
= render "projects/buttons/code", dropdown_class: 'dropdown-menu-right', ref: @ref
.project-code-holder.d-block.d-sm-none.mt-sm-2.mt-md-0.ml-md-2>
.project-code-holder.gl-display-flex.gl-gap-3{ class: 'gl-sm-display-none!' }
= render 'projects/buttons/download', project: @project, ref: @ref
= render "shared/mobile_clone_panel", ref: @ref

3
app/views/shared/_web_ide_button.html.haml
View File

@ -1,5 +1,6 @@
- type = blob ? 'blob' : 'tree'
- button_data = web_ide_button_data({ blob: blob })
- fork_options = fork_modal_options(@project, blob)
- css_classes = false unless local_assigns[:css_classes]
.gl-display-inline-block{ data: { options: button_data.merge(fork_options).to_json, web_ide_promo_popover_img: image_path('web-ide-promo-popover.svg') }, id: "js-#{type}-web-ide-link" }
.gl-display-inline-block{ data: { options: button_data.merge(fork_options).to_json, web_ide_promo_popover_img: image_path('web-ide-promo-popover.svg'), css_classes: css_classes }, id: "js-#{type}-web-ide-link" }

7
config/vite.json
View File

@ -1,6 +1,13 @@
{
"all": {
"sourceCodeDir": "app/assets",
"watchAdditionalPaths": [
"app/graphql/queries",
"app/assets",
"ee/app/assets",
"jh/app/assets",
"vendor/assets"
],
"entrypointsDir": "javascripts/entrypoints",
"port": 3038,
"publicOutputDir": "vite-dev",

2
doc/administration/gitaly/concurrency_limiting.md
View File

@ -163,7 +163,7 @@ The adaptive limiter calibrates the limits every 30 seconds and:
or CPU throttled for 50% or more of the observation time.
Otherwise, the limits increase by one until reaching the upper bound. For more information about technical implementation
of this system, please refer to [this blueprint](../../architecture/blueprints/gitaly_adaptive_concurrency_limit/index.md).
of this system, refer to [this blueprint](../../architecture/blueprints/gitaly_adaptive_concurrency_limit/index.md).
Adaptive limiting is enabled for each RPC or pack-objects cache individually. However, limits are calibrated at the same time.

4
doc/administration/postgresql/replication_and_failover.md
View File

@ -275,7 +275,7 @@ gitlab_rails['auto_migrate'] = false
consul['services'] = %w(postgresql)
# START user configuration
# Please set the real values as explained in Required Information section
# Set the real values as explained in Required Information section
#
# Replace PGBOUNCER_PASSWORD_HASH with a generated md5 value
postgresql['pgbouncer_user_password'] = 'PGBOUNCER_PASSWORD_HASH'
@ -427,7 +427,7 @@ authentication mode (`patroni['tls_client_mode']`), must each have the same valu
consul['watchers'] = %w(postgresql)
# START user configuration
# Please set the real values as explained in Required Information section
# Set the real values as explained in Required Information section
# Replace CONSUL_PASSWORD_HASH with with a generated md5 value
# Replace PGBOUNCER_PASSWORD_HASH with with a generated md5 value
pgbouncer['users'] = {

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

@ -91,7 +91,7 @@ Outbound communications from the following features are silenced by Silent Mode.
| [Executable integrations](../../user/project/integrations/index.md) | The integrations are not executed. |
| [Service Desk](../../user/project/service_desk/index.md) | Incoming emails still raise issues, but the users who sent the emails to Service Desk are not notified of issue creation or comments on their issues. |
| Outbound emails | |
| Outbound HTTP requests | Many HTTP requests are blocked where features are not blocked or skipped explicitly. These may produce errors. If a particular error is problematic for testing during Silent Mode, please consult [GitLab Support](https://about.gitlab.com/support/). |
| Outbound HTTP requests | Many HTTP requests are blocked where features are not blocked or skipped explicitly. These may produce errors. If a particular error is problematic for testing during Silent Mode, consult [GitLab Support](https://about.gitlab.com/support/). |
### Outbound communications that are not silenced

3
doc/api/group_milestones.md
View File

@ -35,7 +35,8 @@ Parameters:
| `title` | string | no | Return only the milestones having the given `title` |
| `search` | string | no | Return only milestones with a title or description matching the provided string |
| `include_parent_milestones` | boolean | no | [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/433298) in GitLab 16.7. Use `include_ancestors` instead. |
| `include_ancestors` | boolean | no | Include milestones from all parent groups. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/196066) in GitLab 13.4. |
| `include_ancestors` | boolean | no | Include milestones for all parent groups. |
| `include_descendants` | boolean | no | Include milestones for group and its descendants. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/421030) in GitLab 16.7. |
| `updated_before` | datetime | no | Return only milestones updated before the given datetime. Expected in ISO 8601 format (`2019-03-15T08:00:00Z`). Introduced in GitLab 15.10 |
| `updated_after` | datetime | no | Return only milestones updated after the given datetime. Expected in ISO 8601 format (`2019-03-15T08:00:00Z`). Introduced in GitLab 15.10 |

2
doc/api/oauth2.md
View File

@ -72,7 +72,7 @@ parameter, which are securely bound to the user agent", with each request to the
### Use HTTPS in production
For production, please use HTTPS for your `redirect_uri`.
For production, use HTTPS for your `redirect_uri`.
For development, GitLab allows insecure HTTP redirect URIs.
As OAuth 2.0 bases its security entirely on the transport layer, you should not use unprotected

2
doc/api/project_vulnerabilities.md
View File

@ -16,7 +16,7 @@ info: "To determine the technical writer assigned to the Stage/Group associated
WARNING:
This API is in the process of being deprecated and considered unstable.
The response payload may be subject to change or breakage
across GitLab releases. Please use the
across GitLab releases. Use the
[GraphQL API](graphql/reference/index.md#queryvulnerabilities)
instead.

2
doc/architecture/blueprints/_template.md
View File

@ -13,7 +13,7 @@ Before you start:
- Copy this file to a sub-directory and call it `index.md` for it to appear in
the blueprint directory.
- Please remove comment blocks for sections you've filled in.
- Remove comment blocks for sections you've filled in.
When your blueprint ready for review, all of these comment blocks should be
removed.

78
doc/architecture/blueprints/capacity_planning/index.md
View File

@ -13,21 +13,27 @@ approvers: [ "@swiskow", "@rnienaber", "@o-lluch" ]
## Summary
This document outlines how we plan to set up infrastructure capacity planning for GitLab Dedicated tenant environments, which is a [FY24-Q3 OKR](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/3507).
This document outlines how we plan to set up infrastructure capacity planning for GitLab Dedicated tenant environments, which started as a [FY24-Q3 OKR](https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/3507).
We make use of Tamland, a tool we built to provide saturation forecasting insights for GitLab.com infrastructure resources. We propose to include Tamland as a part of the GitLab Dedicated stack and execute forecasting from within the tenant environments.
We make use of [Tamland](https://gitlab.com/gitlab-com/gl-infra/tamland), a tool we build to provide saturation forecasting insights for GitLab.com infrastructure resources.
We propose to include Tamland as a part of the GitLab Dedicated stack and execute forecasting from within the tenant environments.
Tamland predicts SLO violations and their respective dates, which need to be reviewed and acted upon. In terms of team organisation, the Dedicated team is proposed to own the tenant-side setup for Tamland and to own the predicted SLO violations, with the help and guidance of the Scalability::Projections team, which drives further development, documentation and overall guidance for capacity planning, including for Dedicated.
Tamland predicts SLO violations and their respective dates, which need to be reviewed and acted upon.
In terms of team organisation, the Dedicated team is proposed to own the tenant-side setup for Tamland and to own the predicted SLO violations, with the help and guidance of the Scalability::Projections team, which drives further development, documentation and overall guidance for capacity planning, including for Dedicated.
With this setup, we aim to turn Tamland into a more generic tool, which can be used in various environments including but not limited to Dedicated tenants. Long-term, we think of including Tamland in self-managed installations and think of Tamland as a candidate for open source release.
With this setup, we aim to turn Tamland into a more generic tool, which can be used in various environments including but not limited to Dedicated tenants.
Long-term, we think of including Tamland in self-managed installations and think of Tamland as a candidate for open source release.
## Motivation
### Background: Capacity planning for GitLab.com
[Tamland](https://gitlab.com/gitlab-com/gl-infra/tamland) is an infrastructure resource forecasting project owned by the [Scalability::Projections](https://about.gitlab.com/handbook/engineering/infrastructure/team/scalability/projections.html) group. It implements [capacity planning](https://about.gitlab.com/handbook/engineering/infrastructure/capacity-planning/) for GitLab.com, which is a [controlled activity covered by SOC 2](https://gitlab.com/gitlab-com/gl-security/security-assurance/security-compliance-commercial-and-dedicated/observation-management/-/issues/604). As of today, it is used exclusively for GitLab.com to predict upcoming SLO violations across hundreds of monitored infrastructure components.
[Tamland](https://gitlab.com/gitlab-com/gl-infra/tamland) is an infrastructure resource forecasting project owned by the [Scalability::Observability](https://about.gitlab.com/handbook/engineering/infrastructure/team/scalability/#scalabilityobservability) group.
It implements [capacity planning](https://about.gitlab.com/handbook/engineering/infrastructure/capacity-planning/) for GitLab.com, which is a [controlled activity covered by SOC 2](https://gitlab.com/gitlab-com/gl-security/security-assurance/security-compliance-commercial-and-dedicated/observation-management/-/issues/604).
As of today, it is used exclusively for GitLab.com to predict upcoming SLO violations across hundreds of monitored infrastructure components.
Tamland produces a [report](https://gitlab-com.gitlab.io/gl-infra/tamland/intro.html) (hosted on GitLab Pages) containing forecast plots, information around predicted violations and other information around the components monitored. Any predicted SLO violation result in a capacity warning issue being created in the [issue tracker for capacity planning](https://gitlab.com/gitlab-com/gl-infra/capacity-planning/-/boards/2816983) on GitLab.com.
Tamland produces a [report](https://gitlab-com.gitlab.io/gl-infra/tamland/intro.html) (hosted on GitLab Pages) containing forecast plots, information around predicted violations and other information around the components monitored.
Any predicted SLO violation result in a capacity warning issue being created in the [issue tracker for capacity planning](https://gitlab.com/gitlab-com/gl-infra/capacity-planning/-/boards/2816983) on GitLab.com.
At present, Tamland is quite tailor made and specific for GitLab.com:
@ -36,21 +42,28 @@ At present, Tamland is quite tailor made and specific for GitLab.com:
[Turning Tamland into a tool](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/1106) we can use more generically and making it independent of GitLab.com specifics is subject of ongoing work.
For illustration, we can see a saturation forecast plot below for the `disk_space` resource for a PostgreSQL service called `patroni-ci`. Within the 90 days forecast horizon, we predict a violation of the `soft` SLO (set at 85% saturation) and this resulted in the creation of a [capacity planning issue](https://gitlab.com/gitlab-com/gl-infra/capacity-planning/-/issues/1219) for further review and potential actions. At present, the Scalability::Projections group reviews those issues and engages with the respective DRI for the service in question to remedy a saturation concern.
For illustration, we can see a saturation forecast plot below for the `disk_space` resource for a PostgreSQL service called `patroni-ci`.
Within the 90 days forecast horizon, we predict a violation of the `soft` SLO (set at 85% saturation) and this resulted in the creation of a [capacity planning issue](https://gitlab.com/gitlab-com/gl-infra/capacity-planning/-/issues/1219) for further review and potential actions.
At present, the Scalability::Projections group reviews those issues and engages with the respective DRI for the service in question to remedy a saturation concern.
<img src="images/image-20230911144743188.png" alt="image-20230911144743188" style="zoom:67%;" />
For GitLab.com capacity planning, we operate Tamland from a scheduled CI pipeline with access to the central Thanos, which provides saturation and utilization metrics for GitLab.com. The CI pipeline produces the desired report, exposes it on GitLab Pages and also creates capacity planning issues. Scalability::Projections runs a capacity planning triage rotation which entails reviewing and prioritizing any open issues and their respective saturation concerns.
For GitLab.com capacity planning, we operate Tamland from a scheduled CI pipeline with access to the central Thanos, which provides saturation and utilization metrics for GitLab.com.
The CI pipeline produces the desired report, exposes it on GitLab Pages and also creates capacity planning issues.
Scalability::Projections runs a capacity planning triage rotation which entails reviewing and prioritizing any open issues and their respective saturation concerns.
### Problem Statement
With the number of [GitLab Dedicated](https://about.gitlab.com/dedicated/) deployments increasing, we need to establish capacity planning processes for Dedicated tenants. This is going to help us notice any pending resource constraints soon enough to be able to upgrade the infrastructure for a given tenant before the resource saturates and causes an incident.
With the number of [GitLab Dedicated](https://about.gitlab.com/dedicated/) deployments increasing, we need to establish capacity planning processes for Dedicated tenants.
This is going to help us notice any pending resource constraints soon enough to be able to upgrade the infrastructure for a given tenant before the resource saturates and causes an incident.
Each Dedicated tenant is an isolated GitLab environment, with a full set of metrics monitored. These metrics are standardized in the [metrics catalog](https://gitlab.com/gitlab-com/runbooks/-/blob/master/reference-architectures/get-hybrid/src/gitlab-metrics-config.libsonnet?ref_type=heads) and on top of these, we have defined saturation metrics along with respective SLOs.
Each Dedicated tenant is an isolated GitLab environment, with a full set of metrics monitored.
These metrics are standardized in the [metrics catalog](https://gitlab.com/gitlab-com/runbooks/-/blob/master/reference-architectures/get-hybrid/src/gitlab-metrics-config.libsonnet?ref_type=heads) and on top of these, we have defined saturation metrics along with respective SLOs.
In order to provide capacity planning and forecasts for saturation metrics for each tenant, we'd like to get Tamland set up for GitLab Dedicated.
While Tamland is developed by the Scalability::Projections and this team also owns the capacity planning process for GitLab.com, they don't have access to any of the Dedicated infrastructure as we have strong isolation implemented for Dedicated environments. As such, the technical design choices are going to affect how those teams interact and vice versa. We include this consideration into this documentation as we think the organisational aspect is a crucial part of it.
While Tamland is developed by the Scalability::Projections and this team also owns the capacity planning process for GitLab.com, they don't have access to any of the Dedicated infrastructure as we have strong isolation implemented for Dedicated environments.
As such, the technical design choices are going to affect how those teams interact and vice versa. We include this consideration into this documentation as we think the organisational aspect is a crucial part of it.
### Key questions
@ -70,25 +83,34 @@ While Tamland is developed by the Scalability::Projections and this team also ow
##### Reporting
As of today, it's not quite clear yet how we'd like to consume forecasting data across tenants. In contrast to GitLab.com, we generate forecasts across a potentially large number of tenants. At this point, we suspect that we're more interested in an aggregate report across tenants rather than individual, very detailed saturation forecasts. As such, this is subject to refinement in a further iteration once we have the underlying data available and gathered practical insight in how we consume this information.
As of today, it's not quite clear yet how we'd like to consume forecasting data across tenants.
In contrast to GitLab.com, we generate forecasts across a potentially large number of tenants.
At this point, we suspect that we're more interested in an aggregate report across tenants rather than individual, very detailed saturation forecasts.
As such, this is subject to refinement in a further iteration once we have the underlying data available and gathered practical insight in how we consume this information.
##### Issue management
While each predicted SLO violation results in the creation of a GitLab issue, this may not be the right mode of raising awareness for Dedicated. Similar to the reporting side, this is subject to further discussion once we have data to look at.
While each predicted SLO violation results in the creation of a GitLab issue, this may not be the right mode of raising awareness for Dedicated.
Similar to the reporting side, this is subject to further discussion once we have data to look at.
##### Customizing forecasting models
Forecasting models can and should be tuned and informed with domain knowledge to produce accurate forecasts. This information is a part of the Tamland manifest. In the first iteration, we don't support per-tenant customization, but this can be added later.
Forecasting models can and should be tuned and informed with domain knowledge to produce accurate forecasts.
This information is a part of the Tamland manifest.
In the first iteration, we don't support per-tenant customization, but this can be added later.
## Proposed Design for Dedicated: A part of the Dedicated stack
Dedicated environments are fully isolated and run their own Prometheus instance to capture metrics, including saturation metrics. Tamland will run from each individual Dedicated tenant environment, consume metrics from Prometheus and store the resulting data in S3. From there, we consume forecast data and act on it.
Dedicated environments are fully isolated and run their own Prometheus instance to capture metrics, including saturation metrics.
Tamland will run from each individual Dedicated tenant environment, consume metrics from Prometheus and store the resulting data in S3.
From there, we consume forecast data and act on it.
![tamland-as-part-of-stack](images/tamland-as-part-of-stack.png)
### Storage for output and cache
Any data Tamland relies on is stored in a S3 bucket. We use one bucket per tenant to clearly separate data between tenants.
Any data Tamland relies on is stored in a S3 bucket.
We use one bucket per tenant to clearly separate data between tenants.
1. Resulting forecast data and other outputs
1. Tamland's internal cache for Prometheus metrics data
@ -97,9 +119,11 @@ There is no need for a persistent state across Tamland runs aside from the S3 bu
### Benefits of executing inside tenant environments
Each Tamland run for a single environment (tenant) can take a few hours to execute. With the number of tenants expected to increase significantly, we need to consider scaling the execution environment for Tamland.
Each Tamland run for a single environment (tenant) can take a few hours to execute.
With the number of tenants expected to increase significantly, we need to consider scaling the execution environment for Tamland.
In this design, Tamland becomes a part of the Dedicated stack and a component of the individual tenant environment. As such, scaling the execution environment for Tamland is solved by design, because tenant forecasts execute inherently parallel in their respective environments.
In this design, Tamland becomes a part of the Dedicated stack and a component of the individual tenant environment.
As such, scaling the execution environment for Tamland is solved by design, because tenant forecasts execute inherently parallel in their respective environments.
### Distribution model: Docker
@ -107,15 +131,18 @@ Tamland is released as a Docker image, see [Tamland's README](https://gitlab.com
### Tamland manifest
The manifest contains information about which saturation metrics to forecast on (see this [manifest example](https://gitlab.com/gitlab-com/gl-infra/tamland/-/blob/62854e1afbc2ed3160a55a738ea587e0cf7f994f/saturation.json) for GitLab.com). This will be generated from the metrics catalog and will be the same for all tenants for starters.
The manifest contains information about which saturation metrics to forecast on (see this [manifest example](https://gitlab.com/gitlab-com/gl-infra/tamland/-/blob/62854e1afbc2ed3160a55a738ea587e0cf7f994f/saturation.json) for GitLab.com).
This will be generated from the metrics catalog and will be the same for all tenants for starters.
In order to generate the manifest from the metrics catalog, we setup dedicated GitLab project `tamland-dedicated` . On a regular basis, a scheduled pipeline grabs the metrics catalog, generates the JSON manifest from it and commits this to the project.
In order to generate the manifest from the metrics catalog, we setup dedicated GitLab project `tamland-dedicated`.
On a regular basis, a scheduled pipeline grabs the metrics catalog, generates the JSON manifest from it and commits this to the project.
On the Dedicated tenants, we download the latest version of the committed JSON manifest from `tamland-dedicated` and use this as input to execute Tamland.
### Acting on forecast insights
When Tamland forecast data is available for a tenant, the Dedicated teams consume this data and act on it accordingly. The Scalability::Projections group is going to support and guide this process to get started and help interpret data, along with implementing Tamland features required to streamline this process for Dedicated in further iterations.
When Tamland forecast data is available for a tenant, the Dedicated teams consume this data and act on it accordingly.
The Scalability::Observability group is going to support and guide this process to get started and help interpret data, along with implementing Tamland features required to streamline this process for Dedicated in further iterations.
## Alternative Solution
@ -125,11 +152,14 @@ An alternative design, we don't consider an option at this point, is to setup Ta
![tamland-as-a-service](images/tamland-as-a-service.png)
In this design, a central Prometheus/Thanos instance is needed to provide the metrics data for Tamland. Dedicated tenants use remote-write to push their Prometheus data to the central Thanos instance.
In this design, a central Prometheus/Thanos instance is needed to provide the metrics data for Tamland.
Dedicated tenants use remote-write to push their Prometheus data to the central Thanos instance.
Tamland is set up to run on a regular basis and consume metrics data from the single Thanos instance. It stores its results and cache in S3, similar to the other design.
Tamland is set up to run on a regular basis and consume metrics data from the single Thanos instance.
It stores its results and cache in S3, similar to the other design.
In order to execute forecasts regularly, we need to provide an execution environment to run Tamland in. With an increasing number of tenants, we'd need to scale up resources for this cluster.
In order to execute forecasts regularly, we need to provide an execution environment to run Tamland in.
With an increasing number of tenants, we'd need to scale up resources for this cluster.
This design **has not been chosen** because of both technical and organisational concerns:

2
doc/architecture/blueprints/consolidating_groups_and_projects/index.md
View File

@ -230,7 +230,7 @@ We should strive to do the code clean up as we move through the phases. However,
The initial iteration will provide a framework to house features under `Namespaces`. Stage groups will eventually need to migrate their own features and functionality over to `Namespaces`. This may impact these features in unexpected ways. Therefore, to minimize UX debt and maintain product consistency, stage groups will have to consider several factors when migrating their features over to `Namespaces`:
1. **Conceptual model**: What are the current and future state conceptual models of these features ([see object modeling for designers](https://hpadkisson.medium.com/object-modeling-for-designers-an-introduction-7871bdcf8baf))? These should be documented in Pajamas (example: [merge requests](https://design.gitlab.com/objects/merge-request/)).
1. **Merge conflicts**: What inconsistencies are there across project, group, and administrator levels? How might these be addressed? For an example of how we rationalized this for labels, please see [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/338820).
1. **Merge conflicts**: What inconsistencies are there across project, group, and administrator levels? How might these be addressed? For an example of how we rationalized this for labels, see [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/338820).
1. **Inheritance & information flow**: How is information inherited across our container hierarchy currently? How might this be impacted if complying with the new [inheritance behavior](https://gitlab.com/gitlab-org/gitlab/-/issues/343316) framework?
1. **Settings**: Where can settings for this feature be found currently? How will these be impacted by `Namespaces`?
1. **Access**: Who can access this feature and is that impacted by the new container structure? Are there any role or privacy considerations?

6
doc/architecture/blueprints/container_registry_metadata_database/index.md
View File

@ -65,7 +65,7 @@ sequenceDiagram
Note right of C: Bearer token included in the Authorization header
```
Please refer to the [Docker documentation](https://docs.docker.com/registry/spec/auth/token/) for more details.
For more details, refer to the [Docker documentation](https://docs.docker.com/registry/spec/auth/token/).
##### Push and Pull
@ -164,7 +164,7 @@ Although blobs are shared across repositories, manifest and tag metadata are sco
#### GitLab.com
Due to scale, performance and isolation concerns, for GitLab.com the registry database will be on a separate dedicated PostgreSQL cluster. Please see [#93](https://gitlab.com/gitlab-org/container-registry/-/issues/93) and [GitLab-com/gl-infra/reliability#10109](https://gitlab.com/gitlab-com/gl-infra/reliability/-/issues/10109) for additional context.
Due to scale, performance and isolation concerns, for GitLab.com the registry database will be on a separate dedicated PostgreSQL cluster. See [#93](https://gitlab.com/gitlab-org/container-registry/-/issues/93) and [GitLab-com/gl-infra/reliability#10109](https://gitlab.com/gitlab-com/gl-infra/reliability/-/issues/10109) for additional context.
The diagram below illustrates the architecture of the database cluster:
@ -238,7 +238,7 @@ This is a list of all the registry HTTP API operations and how they depend on th
| [Complete blob upload](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/spec/api.md#put-blob-upload) | `PUT` | `/v2/<name>/blobs/uploads/<uuid>` | **{check-circle}** Yes | **{check-circle}** Yes | **{dotted-circle}** No |
| [Cancel blob upload](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/spec/api.md#canceling-an-upload) | `DELETE` | `/v2/<name>/blobs/uploads/<uuid>` | **{check-circle}** Yes | **{check-circle}** Yes | **{dotted-circle}** No |
`*` Please refer to the [list of interactions between registry and Rails](#from-gitlab-rails-to-registry) to know why and how.
`*` Refer to the [list of interactions between registry and Rails](#from-gitlab-rails-to-registry) to know why and how.
#### Failure Scenarios

2
doc/architecture/blueprints/container_registry_metadata_database_self_managed_rollout/index.md
View File

@ -88,7 +88,7 @@ The metadata database is in early beta for self-managed users. The core migratio
process for existing registries has been implemented, and online garbage collection
is fully implemented. Certain database enabled features are only enabled for GitLab.com
and automatic database provisioning for the registry database is not available.
Please see the table below for the status of features related to the container
See the table below for the status of features related to the container
registry database.
| Feature | Description | Status | Link |

2
doc/architecture/blueprints/gitaly_handle_upload_pack_in_http2_server/index.md
View File

@ -28,7 +28,7 @@ provided. We are looking for a solution that won't require us to completely rewr
### How Git data transfer works
Please skip this part if you are familiar with how Git data transfer architecture at GitLab.
Skip this part if you are familiar with how Git data transfer architecture at GitLab.
Git data transfer is undeniably one of the crucial services that a Git server can offer. It is a fundamental feature of Git that was originally developed for Linux
kernel development. As Git gained popularity, it continued to be recognized as a distributed system. However, the emergence of centralized Git services like GitHub or

6
doc/architecture/blueprints/google_artifact_registry_integration/index.md
View File

@ -18,7 +18,7 @@ As highlighted in the announcement, one key goal is the ability to "_use Google'
## Motivation
Please refer to the [announcement](https://about.gitlab.com/blog/2023/08/29/gitlab-google-partnership-s3c/) blog post for more details about the motivation and long-term goals of the GitLab and Google Cloud partnership.
Refer to the [announcement](https://about.gitlab.com/blog/2023/08/29/gitlab-google-partnership-s3c/) blog post for more details about the motivation and long-term goals of the GitLab and Google Cloud partnership.
Regarding the scope of this design document, our primary focus is to fulfill the Product requirement of providing users with visibility over their container images in GAR. The motivation for this specific goal is rooted in foundational research on the use of external registries as a complement to the GitLab container registry ([internal](https://gitlab.com/gitlab-org/ux-research/-/issues/2602)).
@ -82,13 +82,13 @@ Regarding the GAR integration, since there is no equivalent entities for GitLab
GAR provides three APIs: Docker API, REST API, and RPC API.
The [Docker API](https://cloud.google.com/artifact-registry/docs/reference/docker-api) is based on the [Docker Registry HTTP API V2](https://docs.docker.com/registry/spec/api), now superseded by the [OCI Distribution Specification API](https://github.com/opencontainers/distribution-spec/blob/main/spec.md) (from now on referred to as OCI API). This API is used for pushing/pulling images to/from GAR and also provides some discoverability operations. Please refer to [Alternative Solutions](#alternative-solutions) for the reasons why we don't intend to use it.
The [Docker API](https://cloud.google.com/artifact-registry/docs/reference/docker-api) is based on the [Docker Registry HTTP API V2](https://docs.docker.com/registry/spec/api), now superseded by the [OCI Distribution Specification API](https://github.com/opencontainers/distribution-spec/blob/main/spec.md) (from now on referred to as OCI API). This API is used for pushing/pulling images to/from GAR and also provides some discoverability operations. Refer to [Alternative Solutions](#alternative-solutions) for the reasons why we don't intend to use it.
Among the proprietary GAR APIs, the [REST API](https://cloud.google.com/artifact-registry/docs/reference/rest) provides basic functionality for managing repositories. This includes [`list`](https://cloud.google.com/artifact-registry/docs/reference/rest/v1/projects.locations.repositories.dockerImages/list) and [`get`](https://cloud.google.com/artifact-registry/docs/reference/rest/v1/projects.locations.repositories.dockerImages/get) operations for container image repositories, which could be used for this integration. Both operations return the same data structure, represented by the [`DockerImage`](https://cloud.google.com/artifact-registry/docs/reference/rest/v1/projects.locations.repositories.dockerImages#DockerImage) object, so both provide the same level of detail.
Last but not least, there is also an [RPC API](https://cloud.google.com/artifact-registry/docs/reference/rpc/google.devtools.artifactregistry.v1), backed by gRPC and Protocol Buffers. This API provides the most functionality, covering all GAR features. From the available operations, we can make use of the [`ListDockerImagesRequest`](https://cloud.google.com/artifact-registry/docs/reference/rpc/google.devtools.artifactregistry.v1#listdockerimagesrequest) and [`GetDockerImageRequest`](https://cloud.google.com/artifact-registry/docs/reference/rpc/google.devtools.artifactregistry.v1#google.devtools.artifactregistry.v1.GetDockerImageRequest) operations. As with the REST API, both responses are composed of [`DockerImage`](https://cloud.google.com/artifact-registry/docs/reference/rpc/google.devtools.artifactregistry.v1#google.devtools.artifactregistry.v1.DockerImage) objects.
Between the two proprietary API options, we chose the RPC one because it provides support not only for the operations we need today but also offers better coverage of all GAR features, which will be beneficial in future iterations. Finally, we do not intend to make direct use of this API but rather use it through the official Ruby client SDK. Please see [Client SDK](backend.md#client-sdk) below for more details.
Between the two proprietary API options, we chose the RPC one because it provides support not only for the operations we need today but also offers better coverage of all GAR features, which will be beneficial in future iterations. Finally, we do not intend to make direct use of this API but rather use it through the official Ruby client SDK. See [Client SDK](backend.md#client-sdk) below for more details.
#### Backend Integration

4
doc/architecture/blueprints/observability_logging/index.md
View File

@ -121,7 +121,7 @@ Hence the decision to only support Log objects seems like a boring and simple so
Similar to traces, logging data ingestion will be done at the Ingress level.
As part of [the forward-auth](https://doc.traefik.io/traefik/middlewares/http/forwardauth/) flow, Traefik will forward the request to Gatekeeper which in turn leverages Redis for counting.
This is currently done only for [the ingestion path](https://gitlab.com/gitlab-org/opstrace/opstrace/-/merge_requests/2236).
Please check the MR description for more details on how it works.
Check the MR description for more details on how it works.
The read path rate limiting implementation is tracked [here](https://gitlab.com/gitlab-org/opstrace/opstrace/-/issues/2356).
### Database schema
@ -629,4 +629,4 @@ Long-term, we will need a way to monitor the number of user queries that failed
## Iterations
Please refer to [Observability Group planning epic](https://gitlab.com/groups/gitlab-org/opstrace/-/epics/92) and its linked issues for up-to-date information.
Refer to [Observability Group planning epic](https://gitlab.com/groups/gitlab-org/opstrace/-/epics/92) and its linked issues for up-to-date information.

2
doc/architecture/blueprints/runner_tokens/index.md
View File

@ -440,7 +440,7 @@ scope.
## FAQ
Please follow [the user documentation](../../../ci/runners/new_creation_workflow.md).
Follow [the user documentation](../../../ci/runners/new_creation_workflow.md).
## Status

2
doc/cloud_seed/index.md
View File

@ -120,7 +120,7 @@ The following databases and versions are supported:
- 2019: Standard, Enterprise, Express, and Web
- 2017: Standard, Enterprise, Express, and Web
Google Cloud pricing applies. Please refer to the [Cloud SQL pricing page](https://cloud.google.com/sql/pricing).
Google Cloud pricing applies. Refer to the [Cloud SQL pricing page](https://cloud.google.com/sql/pricing).
1. [Create a database instance](#create-a-database-instance)
1. [Database setup through a background worker](#database-setup-through-a-background-worker)

10
doc/development/advanced_search.md
View File

@ -32,7 +32,7 @@ See the [Elasticsearch GDK setup instructions](https://gitlab.com/gitlab-org/git
- `gitlab:elastic:test:index_size`: Tells you how much space the current index is using, as well as how many documents are in the index.
- `gitlab:elastic:test:index_size_change`: Outputs index size, reindexes, and outputs index size again. Useful when testing improvements to indexing size.
Additionally, if you need large repositories or multiple forks for testing, please consider [following these instructions](rake_tasks.md#extra-project-seed-options)
Additionally, if you need large repositories or multiple forks for testing, consider [following these instructions](rake_tasks.md#extra-project-seed-options)
## How does it work?
@ -40,7 +40,7 @@ The Elasticsearch integration depends on an external indexer. We ship an [indexe
After initial indexing is complete, create, update, and delete operations for all models except projects (see [#207494](https://gitlab.com/gitlab-org/gitlab/-/issues/207494)) are tracked in a Redis [`ZSET`](https://redis.io/docs/manual/data-types/#sorted-sets). A regular `sidekiq-cron` `ElasticIndexBulkCronWorker` processes this queue, updating many Elasticsearch documents at a time with the [Bulk Request API](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-bulk.html).
Search queries are generated by the concerns found in [`ee/app/models/concerns/elastic`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/ee/app/models/concerns/elastic). These concerns are also in charge of access control, and have been a historic source of security bugs so please pay close attention to them!
Search queries are generated by the concerns found in [`ee/app/models/concerns/elastic`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/ee/app/models/concerns/elastic). These concerns are also in charge of access control, and have been a historic source of security bugs so pay close attention to them!
### Custom routing
@ -62,13 +62,13 @@ The following analyzers and tokenizers are defined in [`ee/lib/elastic/latest/co
Used when indexing blobs' paths. Uses the `path_tokenizer` and the `lowercase` and `asciifolding` filters.
Please see the `path_tokenizer` explanation below for an example.
See the `path_tokenizer` explanation below for an example.
#### `sha_analyzer`
Used in blobs and commits. Uses the `sha_tokenizer` and the `lowercase` and `asciifolding` filters.
Please see the `sha_tokenizer` explanation later below for an example.
See the `sha_tokenizer` explanation later below for an example.
#### `code_analyzer`
@ -76,7 +76,7 @@ Used when indexing a blob's filename and content. Uses the `whitespace` tokenize
The `whitespace` tokenizer was selected to have more control over how tokens are split. For example the string `Foo::bar(4)` needs to generate tokens like `Foo` and `bar(4)` to be properly searched.
Please see the `code` filter for an explanation on how tokens are split.
See the `code` filter for an explanation on how tokens are split.
NOTE:
The [Elasticsearch `code_analyzer` doesn't account for all code cases](../integration/advanced_search/elasticsearch_troubleshooting.md#elasticsearch-code_analyzer-doesnt-account-for-all-code-cases).

2
doc/development/ai_architecture.md
View File

@ -19,7 +19,7 @@ The following diagram from the [architecture blueprint](../architecture/blueprin
## SaaS-based AI abstraction layer
GitLab currently operates a cloud-hosted AI architecture. We will allow access to it for licensed self managed instances using the AI-gateway. Please see [the blueprint](../architecture/blueprints/ai_gateway) for details
GitLab currently operates a cloud-hosted AI architecture. We will allow access to it for licensed self managed instances using the AI-gateway. See [the blueprint](../architecture/blueprints/ai_gateway) for details.
There are two primary reasons for this: the best AI models are cloud-based as they often depend on specialized hardware designed for this purpose, and operating self-managed infrastructure capable of AI at-scale and with appropriate performance is a significant undertaking. We are actively [tracking self-managed customers interested in AI](https://gitlab.com/gitlab-org/gitlab/-/issues/409183).

2
doc/development/ai_features/glossary.md
View File

@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
This is a list of terms that may have a general meaning but also may have a
specific meaning at GitLab. If you encounter a piece of technical jargon related
to AI that you think could benefit from being in this list, please add it!
to AI that you think could benefit from being in this list, add it!
- **AI Gateway**: standalone service used to give access to AI features to
non-SaaS GitLab users. This logic will be moved to Cloud Connector when that

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

@ -93,7 +93,7 @@ For features that use the embedding database, additional setup is needed.
### Configure GCP Vertex access
In order to obtain a GCP service key for local development, please follow the steps below:
In order to obtain a GCP service key for local development, follow the steps below:
- Create a sandbox GCP project by visiting [this page](https://about.gitlab.com/handbook/infrastructure-standards/#individual-environment) and following the instructions, or by requesting access to our existing group GCP project by using [this template](https://gitlab.com/gitlab-com/it/infra/issue-tracker/-/issues/new?issuable_template=gcp_group_account_iam_update_request).
- If you are using an individual GCP project, you may also need to enable the Vertex AI API:

2
doc/development/api_graphql_styleguide.md
View File

@ -58,7 +58,7 @@ For example, the one for [GitLab.com](https://gitlab.com/-/graphql-explorer).
The GraphQL framework has some specific gotchas to be aware of, and domain expertise is required to ensure they are satisfied.
If you are asked to review a merge request that modifies any GraphQL files or adds an endpoint, please have a look at
If you are asked to review a merge request that modifies any GraphQL files or adds an endpoint, have a look at
[our GraphQL review guide](graphql_guide/reviewing.md).
## Reading GraphQL logs

4
doc/development/api_styleguide.md
View File

@ -10,7 +10,7 @@ This style guide recommends best practices for API development.
## Instance variables
Please do not use instance variables, there is no need for them (we don't need
Don't use instance variables, there is no need for them (we don't need
to access them as we do in Rails views), local variables are fine.
## Entities
@ -321,7 +321,7 @@ it's own file in the [`validators`](https://gitlab.com/gitlab-org/gitlab/-/blob/
## Internal API
The [internal API](internal_api/index.md) is documented for internal use. Please keep it up to date so we know what endpoints
The [internal API](internal_api/index.md) is documented for internal use. Keep it up to date so we know what endpoints
different components are making use of.
## Avoiding N+1 problems

2
doc/development/application_secrets.md
View File

@ -46,4 +46,4 @@ GitLab.com environments prior to changing this file.
## Further iteration
We may either deprecate or remove this automatic secret generation `01_secret_token.rb` in the future.
Please see [issue 222690](https://gitlab.com/gitlab-org/gitlab/-/issues/222690) for more information.
See [issue 222690](https://gitlab.com/gitlab-org/gitlab/-/issues/222690) for more information.

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

@ -179,7 +179,7 @@ In [this project](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/614)
we are extending this so alerts for SLIs with a `feature_category`
label in the source metrics can also be routed.
For any question, please don't hesitate to create an issue in
For any question, don't hesitate to create an issue in
[the Scalability issue tracker](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues)
or come find us in
[#g_scalability](https://gitlab.slack.com/archives/CMMF8TKR9) on Slack.

4
doc/development/application_slis/rails_request.md
View File

@ -126,7 +126,7 @@ a case-by-case basis. Take the following into account:
view. We cannot scale up the fleet fast enough to accommodate for
the incoming slow requests alongside the regular traffic.
When lowering the urgency for an existing endpoint, please involve a
When lowering the urgency for an existing endpoint, involve a
[Scalability team member](https://about.gitlab.com/handbook/engineering/infrastructure/team/scalability/#team-members)
in the review. We can use request rates and durations available in the
logs to come up with a recommendation. You can pick a threshold
@ -172,7 +172,7 @@ information in the logs to check:
the target duration we want to set.
As decreasing a threshold too much could result in alerts for the
Apdex degradation, please also involve a Scalability team member in
Apdex degradation, also involve a Scalability team member in
the merge request.
## How to adjust the urgency

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

@ -23,7 +23,7 @@ While any events could trigger an Audit Event, not all events should. In general
- Are tracking information for product feature adoption.
- Are covered in the direction page's discussion on [what is not planned](https://about.gitlab.com/direction/govern/compliance/audit-events/#what-is-not-planned-right-now).
If you have any questions, please reach out to `@gitlab-org/govern/compliance` to see if an Audit Event, or some other approach, may be best for your event.
If you have any questions, reach out to `@gitlab-org/govern/compliance` to see if an Audit Event, or some other approach, may be best for your event.
## Audit Event Schemas

2
doc/development/avoiding_required_stops.md
View File

@ -32,7 +32,7 @@ Wherever possible, a required stop should be avoided. If it can't be avoided,
the required stop should be aligned to a _scheduled_ required stop.
In cases where we are considering retroactively declaring an unplanned required stop,
please contact the [Distribution team product manager](https://about.gitlab.com/handbook/product/categories/#distributionbuild-group) to advise on next steps. If there
contact the [Distribution team product manager](https://about.gitlab.com/handbook/product/categories/#distributionbuild-group) to advise on next steps. If there
is uncertainty about whether we should declare a required stop, the Distribution product
manager may escalate to GitLab product leadership (VP or Chief Product Officer) to make
a final determination. This may happen, for example, if a change might require a stop for

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

@ -8,7 +8,7 @@ info: Any user with at least the Maintainer role can merge updates to this conte
Development guides that are specific to CI/CD are listed here:
- If you are creating new CI/CD templates, please read [the development guide for GitLab CI/CD templates](templates.md).
- If you are creating new CI/CD templates, read [the development guide for GitLab CI/CD templates](templates.md).
- If you are adding a new keyword or changing the CI schema, check the [CI schema guide](schema.md)
See the [CI/CD YAML reference documentation guide](cicd_reference_documentation_guide.md)

6
doc/development/cicd/templates.md
View File

@ -284,7 +284,7 @@ the user's `.gitlab-ci.yml` immediately causes a lint error because there
are no such jobs named `performance` in the included template anymore. Therefore,
users have to fix their `.gitlab-ci.yml` that could annoy their workflow.
Please read [versioning](#versioning) section for introducing breaking change safely.
Read [versioning](#versioning) section for introducing breaking change safely.
## Versioning
@ -377,7 +377,7 @@ Each CI/CD template must be tested to make sure that it's safe to be published.
### Manual QA
It's always good practice to test the template in a minimal demo project.
To do so, please follow the following steps:
To do so, follow the following steps:
1. Create a public sample project on <https://gitlab.com>.
1. Add a `.gitlab-ci.yml` to the project with the proposed template.
@ -481,6 +481,6 @@ If you're unsure if it's secure or not, you must ask security experts for cross-
After your CI/CD template MR is created and labeled with `ci::templates`, DangerBot
suggests one reviewer and one maintainer that can review your code. When your merge
request is ready for review, please [mention](../../user/discussions/index.md#mentions)
request is ready for review, [mention](../../user/discussions/index.md#mentions)
the reviewer and ask them to review your CI/CD template changes. See details in the merge request that added
[a DangerBot task for CI/CD template MRs](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/44688).

2
doc/development/code_comments.md
View File

@ -7,7 +7,7 @@ info: Any user with at least the Maintainer role can merge updates to this conte
# Code comments
Whenever you add comment to the code that is expected to be addressed at any time
in future, please create a technical debt issue for it. Then put a link to it
in future, create a technical debt issue for it. Then put a link to it
to the code comment you've created. This allows other developers to quickly
check if a comment is still relevant and what needs to be done to address it.

4
doc/development/code_review.md
View File

@ -251,7 +251,7 @@ See the [test engineering process](https://about.gitlab.com/handbook/engineering
1. You have reviewed the documentation regarding [internal application security reviews](https://about.gitlab.com/handbook/security/#internal-application-security-reviews) for **when** and **how** to request a security review and requested a security review if this is warranted for this change.
1. If there are security scan results that are blocking the MR (due to the [scan result policies](https://gitlab.com/gitlab-com/gl-security/security-policies)):
- For true positive findings, they should be corrected before the merge request is merged. This will remove the AppSec approval required by the scan result policy.
- For false positive findings, something that should be discussed for risk acceptance, or anything questionable, please ping `@gitlab-com/gl-security/appsec`.
- For false positive findings, something that should be discussed for risk acceptance, or anything questionable, ping `@gitlab-com/gl-security/appsec`.
##### Deployment
@ -466,7 +466,7 @@ Here is a summary of the changes, also reflected in this section above.
### Having your merge request reviewed
Please keep in mind that code review is a process that can take multiple
Keep in mind that code review is a process that can take multiple
iterations, and reviewers may spot things later that they may not have seen the
first time.

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

@ -142,7 +142,7 @@ Lastly, keep the following in mind when submitting merge requests:
## Contributing to Premium/Ultimate features with an Enterprise Edition license
If you would like to work on GitLab features that are within a paid tier, also known as the code that lives in the [EE folder](https://gitlab.com/gitlab-org/gitlab/-/tree/master/ee), it requires a GitLab Enterprise Edition license.
Please request an Enterprise Edition Developers License according to the [documented process](https://about.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows.html#contributing-to-the-gitlab-enterprise-edition-ee).
Request an Enterprise Edition Developers License according to the [documented process](https://about.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows.html#contributing-to-the-gitlab-enterprise-edition-ee).
## Get help

6
doc/development/contributing/issue_workflow.md
View File

@ -34,7 +34,7 @@ In order to help track feature proposals, we use the
Users that are not members of the project cannot add labels via the UI.
Instead, use [reactive label commands](https://about.gitlab.com/handbook/engineering/quality/triage-operations/#reactive-label-and-unlabel-commands).
Please keep feature proposals as small and simple as possible, complex ones
Keep feature proposals as small and simple as possible, complex ones
might be edited to make them small and simple.
For changes to the user interface (UI), follow our [design and UI guidelines](design.md),
@ -77,7 +77,7 @@ You are very welcome to help the GitLab team triage issues.
The most important thing is making sure valid issues receive feedback from the
development team. Therefore the priority is mentioning developers that can help
on those issues. Please select someone with relevant experience from the
on those issues. Select someone with relevant experience from the
[GitLab team](https://about.gitlab.com/company/team/).
If there is nobody mentioned with that expertise, look in the commit history for
the affected files to find someone.
@ -120,7 +120,7 @@ with a reference to an issue describing the regression, and then to update that
note with a reference to the merge request that fixes it as it becomes available.
If you're a contributor who doesn't have the required permissions to update
other users' notes, please post a new note with a reference to both the issue
other users' notes, post a new note with a reference to both the issue
and the merge request.
The release manager will

16
doc/development/contributing/merge_request_workflow.md
View File

@ -14,7 +14,7 @@ label, but you are free to contribute to any issue you want.
## Working from issues
If you find an issue, please submit a merge request with a fix or improvement,
If you find an issue, submit a merge request with a fix or improvement,
if you can, and include tests.
If you want to add a new feature that is not labeled, it is best to first create
@ -70,13 +70,13 @@ For a walkthrough of the contribution process, see [Tutorial: Make a GitLab cont
- If you would like quick feedback on your merge request feel free to mention someone
from the [core team](https://about.gitlab.com/community/core-team/) or one of the
[merge request coaches](https://about.gitlab.com/company/team/). When having your code reviewed
and when reviewing merge requests, please keep the [code review guidelines](../code_review.md)
and when reviewing merge requests, keep the [code review guidelines](../code_review.md)
in mind. And if your code also makes changes to the database, or does expensive queries,
check the [database review guidelines](../database_review.md).
### Keep it simple
*Live by smaller iterations.* Please keep the amount of changes in a single MR **as small as possible**.
*Live by smaller iterations.* Keep the amount of changes in a single MR **as small as possible**.
If you want to contribute a large feature, think very carefully about what the
[minimum viable change](https://about.gitlab.com/handbook/product/#the-minimally-viable-change)
is. Can you split the functionality into two smaller MRs? Can you submit only the
@ -156,7 +156,7 @@ Example commit message template that can be used on your machine that embodies t
## Contribution acceptance criteria
To make sure that your merge request can be approved, please ensure that it meets
To make sure that your merge request can be approved, ensure that it meets
the contribution acceptance criteria below:
1. The change is as small as possible.
@ -195,7 +195,7 @@ the contribution acceptance criteria below:
## Definition of done
If you contribute to GitLab, please know that changes involve more than just
If you contribute to GitLab, know that changes involve more than just
code. We use the following [definition of done](https://www.agilealliance.org/glossary/definition-of-done/).
To reach the definition of done, the merge request must create no regressions and meet all these criteria:
@ -263,7 +263,7 @@ requirements.
1. For tests that use Capybara, read
[how to write reliable, asynchronous integration tests](https://thoughtbot.com/blog/write-reliable-asynchronous-integration-tests-with-capybara).
1. [Black-box tests/end-to-end tests](../testing_guide/testing_levels.md#black-box-tests-at-the-system-level-aka-end-to-end-tests)
added if required. Please contact [the quality team](https://about.gitlab.com/handbook/engineering/quality/#teams)
added if required. Contact [the quality team](https://about.gitlab.com/handbook/engineering/quality/#teams)
with any questions.
1. The change is tested in a review app where possible and if appropriate.
1. Code affected by a feature flag is covered by [automated tests with the feature flag enabled and disabled](../feature_flags/index.md#feature-flags-in-tests), or both
@ -275,7 +275,7 @@ requirements.
1. Use available components from the GitLab Design System,
[Pajamas](https://design.gitlab.com/).
1. The MR must include *Before* and *After* screenshots if UI changes are made.
1. If the MR changes CSS classes, please include the list of affected pages, which
1. If the MR changes CSS classes, include the list of affected pages, which
can be found by running `grep css-class ./app -R`.
### Description of changes
@ -323,7 +323,7 @@ Contributions do not require approval from the [Product team](https://about.gitl
## Dependencies
If you add a dependency in GitLab (such as an operating system package) please
If you add a dependency in GitLab (such as an operating system package),
consider updating the following, and note the applicability of each in your merge
request:

2
doc/development/contributing/verify/index.md
View File

@ -242,7 +242,7 @@ scenario relating to a software being built by one of our [early customers](http
> could generate a new particle that would then cause the universe to implode.
That would be quite an undesirable outcome of a small bug in GitLab CI/CD status
processing. Please take extra care when you are working on CI/CD statuses,
processing. Take extra care when you are working on CI/CD statuses,
we don't want to implode our Universe!
This is an extreme and unlikely scenario, but presenting data that is not accurate

2
doc/development/database/database_reviewer_guidelines.md
View File

@ -84,7 +84,7 @@ topics and use cases. The most frequently required during database reviewing are
Database maintainership uses the same process as other projects for identifying maintainers.
[Follow the general process documented here](https://about.gitlab.com/handbook/engineering/workflow/code-review/#how-to-become-a-project-maintainer).
For database specific requirements, please see [`Project maintainer process for gitlab-database`](https://about.gitlab.com/handbook/engineering/workflow/code-review/#project-maintainer-process-for-gitlab-database)
For database specific requirements, see [`Project maintainer process for gitlab-database`](https://about.gitlab.com/handbook/engineering/workflow/code-review/#project-maintainer-process-for-gitlab-database)
## What to do if you feel overwhelmed

2
doc/development/event_store.md
View File

@ -184,7 +184,7 @@ Changes to the schema require multiple rollouts. While the new version is being
- Existing subscribers can consume events using the old version.
- Events get persisted in the Sidekiq queue as job arguments, so we could have 2 versions of the schema during deployments.
As changing the schema ultimately impacts the Sidekiq arguments, please refer to our
As changing the schema ultimately impacts the Sidekiq arguments, refer to our
[Sidekiq style guide](sidekiq/compatibility_across_updates.md#changing-the-arguments-for-a-worker) with regards to multiple rollouts.
#### Add properties

2
doc/development/fe_guide/graphql.md
View File

@ -104,7 +104,7 @@ Default client accepts two parameters: `resolvers` and `config`.
### Multiple client queries for the same object
If you are making multiple queries to the same Apollo client object you might encounter the following error: `Cache data may be lost when replacing the someProperty field of a Query object. To address this problem, either ensure all objects of SomeEntityhave an id or a custom merge function`. We are already checking `id` presence for every GraphQL type that has an `id`, so this shouldn't be the case (unless you see this warning when running unit tests; in this case please ensure your mocked responses contain an `id` whenever it's requested).
If you are making multiple queries to the same Apollo client object you might encounter the following error: `Cache data may be lost when replacing the someProperty field of a Query object. To address this problem, either ensure all objects of SomeEntityhave an id or a custom merge function`. We are already checking `id` presence for every GraphQL type that has an `id`, so this shouldn't be the case (unless you see this warning when running unit tests; in this case ensure your mocked responses contain an `id` whenever it's requested).
When `SomeEntity` type doesn't have an `id` property in the GraphQL schema, to fix this warning we need to define a custom merge function.

6
doc/development/fe_guide/index.md
View File

@ -11,7 +11,7 @@ across the GitLab frontend team.
## Overview
GitLab is built on top of [Ruby on Rails](https://rubyonrails.org). It uses [Haml](https://haml.info/) and a JavaScript-based frontend with [Vue.js](https://vuejs.org). If you are not sure when to use Vue on top of Haml-page, please read [this explanation](vue.md#when-to-add-vue-application).
GitLab is built on top of [Ruby on Rails](https://rubyonrails.org). It uses [Haml](https://haml.info/) and a JavaScript-based frontend with [Vue.js](https://vuejs.org). If you are not sure when to use Vue on top of Haml-page, read [this explanation](vue.md#when-to-add-vue-application).
<!-- vale gitlab.Spelling = NO -->
@ -19,7 +19,7 @@ Be wary of [the limitations that come with using Hamlit](https://github.com/k0ku
<!-- vale gitlab.Spelling = YES -->
When it comes to CSS, we use a utils-based CSS approach. GitLab has its own CSS utils which are packaged inside the `gitlab-ui` project and can be seen [in the repository](https://gitlab.com/gitlab-org/gitlab-ui/-/tree/main/src/scss/utility-mixins) or on [UNPKG](https://unpkg.com/browse/@gitlab/ui@latest/src/scss/utility-mixins/). Please favor using these before adding or using any SCSS classes.
When it comes to CSS, we use a utils-based CSS approach. GitLab has its own CSS utils which are packaged inside the `gitlab-ui` project and can be seen [in the repository](https://gitlab.com/gitlab-org/gitlab-ui/-/tree/main/src/scss/utility-mixins) or on [UNPKG](https://unpkg.com/browse/@gitlab/ui@latest/src/scss/utility-mixins/). Favor using these before adding or using any SCSS classes.
We also use [SCSS](https://sass-lang.com) and plain JavaScript with
modern ECMAScript standards supported through [Babel](https://babeljs.io/) and ES module support through [webpack](https://webpack.js.org/).
@ -31,7 +31,7 @@ We use [Apollo](https://www.apollographql.com/) as our global state manager and
You should **not** [use VueX and Apollo together](graphql.md#using-with-vuex),
and should [avoid adding new VueX stores](migrating_from_vuex.md) whenever possible.
For copy strings and translations, we have frontend utilities available. Please see the JavaScript section of [Preparing a page for translation](../i18n/externalization.md#javascript-files) for more information.
For copy strings and translations, we have frontend utilities available. See the JavaScript section of [Preparing a page for translation](../i18n/externalization.md#javascript-files) for more information.
Working with our frontend assets requires Node (v12.22.1 or greater) and Yarn
(v1.10.0 or greater). You can find information on how to install these on our

2
doc/development/fe_guide/onboarding_course/index.md
View File

@ -46,7 +46,7 @@ A fortnightly 1-on-1 mentoring sessions are also available to each participant.
There are 10 places available on the course.
The date will be set after the course material has been prepared.
Please complete the [Frontend Onboarding Course Application Form](https://forms.gle/39Rs4w4ZxQuByhE4A) to apply.
Complete the [Frontend Onboarding Course Application Form](https://forms.gle/39Rs4w4ZxQuByhE4A) to apply.
You may also participate in the course informally at your own pace, without the benefit of the synchronous office hours or mentoring session.
GitLab team members are happy to support you regardless.

4
doc/development/fe_guide/vue.md
View File

@ -39,9 +39,9 @@ In the past, we added interactivity to the page piece-by-piece, adding multiple
- multiple applications lead to unpredictable user experience, increased page complexity, harder debugging process;
- the way apps communicate with each other affects Web Vitals numbers.
Because of these reasons, we want to be cautious about adding new Vue applications to the pages where another Vue application is already present (this does not include old or new navigation). Before adding a new app, please make sure that it is absolutely impossible to extend an existing application to achieve a desired functionality. When in doubt, please feel free to ask for the architectural advise on `#frontend` or `#frontend-maintainers` Slack channel.
Because of these reasons, we want to be cautious about adding new Vue applications to the pages where another Vue application is already present (this does not include old or new navigation). Before adding a new app, make sure that it is absolutely impossible to extend an existing application to achieve a desired functionality. When in doubt, feel free to ask for the architectural advise on `#frontend` or `#frontend-maintainers` Slack channel.
If you still need to add a new application, please make sure it shares local state with existing applications (preferably via Apollo Client, or Vuex if we use REST API)
If you still need to add a new application, make sure it shares local state with existing applications (preferably via Apollo Client, or Vuex if we use REST API)
## Vue architecture

2
doc/development/fe_guide/vuex.md
View File

@ -6,7 +6,7 @@ info: Any user with at least the Maintainer role can merge updates to this conte
# Vuex
[Vuex](https://vuex.vuejs.org) should no longer be considered a preferred path to store management and is currently in its legacy phase. This means it is acceptable to add upon existing `Vuex` stores, but we strongly recommend reducing store sizes over time and eventually [migrating away from VueX entirely](migrating_from_vuex.md). Before adding any new `Vuex` store to an application, first ensure that the `Vue` application you plan to add it into **does not use** `Apollo`. `Vuex` and `Apollo` should not be combined unless absolutely necessary. Please consider reading through [our GraphQL documentation](../fe_guide/graphql.md) for more guidelines on how you can build `Apollo` based applications.
[Vuex](https://vuex.vuejs.org) should no longer be considered a preferred path to store management and is currently in its legacy phase. This means it is acceptable to add upon existing `Vuex` stores, but we strongly recommend reducing store sizes over time and eventually [migrating away from VueX entirely](migrating_from_vuex.md). Before adding any new `Vuex` store to an application, first ensure that the `Vue` application you plan to add it into **does not use** `Apollo`. `Vuex` and `Apollo` should not be combined unless absolutely necessary. Consider reading through [our GraphQL documentation](../fe_guide/graphql.md) for more guidelines on how you can build `Apollo` based applications.
The information included in this page is explained in more detail in the
official [Vuex documentation](https://vuex.vuejs.org).

6
doc/development/feature_flags/controls.md
View File

@ -42,7 +42,7 @@ The GitLab feature library (using
[Feature flags process](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/) guide) supports rolling out changes to a percentage of
time to users. This in turn can be controlled using [GitLab ChatOps](../../ci/chatops/index.md).
For an up to date list of feature flag commands please see
For an up to date list of feature flag commands see
[the source code](https://gitlab.com/gitlab-com/chatops/blob/master/lib/chatops/commands/feature.rb).
Note that all the examples in that file must be preceded by
`/chatops run`.
@ -104,7 +104,7 @@ Guidelines:
- Consider notifying `#support_gitlab-com` beforehand. So in case if the feature has any side effects on user experience, they can mitigate and disable the feature flag to reduce some impact.
- If the feature meets the requirements for creating a [Change Management](https://about.gitlab.com/handbook/engineering/infrastructure/change-management/#feature-flags-and-the-change-management-process) issue, create a Change Management issue per [criticality guidelines](https://about.gitlab.com/handbook/engineering/infrastructure/change-management/#change-request-workflows).
- For simple, low-risk, easily reverted features, proceed and [enable the feature in `#production`](#process).
- For support requests to toggle feature flags for specific groups or projects, please follow the process outlined in the [support workflows](https://about.gitlab.com/handbook/support/workflows/saas_feature_flags.html).
- For support requests to toggle feature flags for specific groups or projects, follow the process outlined in the [support workflows](https://about.gitlab.com/handbook/support/workflows/saas_feature_flags.html).
#### Guideline for which percentages to choose during the rollout
@ -203,7 +203,7 @@ Before enabling a feature flag, verify that you are not violating any [Productio
The following `/chatops` commands should be performed in the Slack
`#production` channel.
When you begin to enable the feature, please link to the relevant
When you begin to enable the feature, link to the relevant
feature flag rollout issue within a Slack thread of the first `/chatops`
command you make so people can understand the change if they need to.

4
doc/development/feature_flags/index.md
View File

@ -19,7 +19,7 @@ All newly-introduced feature flags should be [used with an actor](controls.md#pe
This document is the subject of continued work as part of an epic to [improve internal usage of feature flags](https://gitlab.com/groups/gitlab-org/-/epics/3551). Raise any suggestions as new issues and attach them to the epic.
For an [overview of the feature flag lifecycle](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#feature-flag-lifecycle), or if you need help deciding [if you should use a feature flag](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags) or not, please see the [feature flag lifecycle](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/) handbook page.
For an [overview of the feature flag lifecycle](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#feature-flag-lifecycle), or if you need help deciding [if you should use a feature flag](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags) or not, see the [feature flag lifecycle](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/) handbook page.
## When to use feature flags
@ -604,7 +604,7 @@ with the untested code path should be manually tested before deployment to produ
When using the testing environment, all feature flags are enabled by default.
Flags can be disabled by default in the [`spec/spec_helper.rb` file](https://gitlab.com/gitlab-org/gitlab/-/blob/b61fba42eea2cf5bb1ca64e80c067a07ed5d1921/spec/spec_helper.rb#L274).
Please add a comment inline to explain why the flag needs to be disabled. You can also attach the issue URL for reference if possible.
Add a comment inline to explain why the flag needs to be disabled. You can also attach the issue URL for reference if possible.
WARNING:
This does not apply to end-to-end (QA) tests, which [do not enable feature flags by default](#end-to-end-qa-tests). There is a different [process for using feature flags in end-to-end tests](../testing_guide/end_to_end/feature_flags.md).

2
doc/development/features_inside_dot_gitlab.md
View File

@ -7,7 +7,7 @@ info: Any user with at least the Maintainer role can merge updates to this conte
# Features inside the `.gitlab/` directory
We have implemented standard features that depend on configuration files in the `.gitlab/` directory. You can find `.gitlab/` in various GitLab repositories.
When implementing new features, please refer to these existing features to avoid conflicts:
When implementing new features, refer to these existing features to avoid conflicts:
- [Issue Templates](../user/project/description_templates.md#create-an-issue-template): `.gitlab/issue_templates/`.
- [Merge request Templates](../user/project/description_templates.md#create-a-merge-request-template): `.gitlab/merge_request_templates/`.

2
doc/development/file_storage.md
View File

@ -8,7 +8,7 @@ info: Any user with at least the Maintainer role can merge updates to this conte
We use the [CarrierWave](https://github.com/carrierwaveuploader/carrierwave) gem to handle file upload, store and retrieval.
File uploads should be accelerated by workhorse, for details please refer to [uploads development documentation](uploads/index.md).
File uploads should be accelerated by workhorse, for details refer to [uploads development documentation](uploads/index.md).
There are many places where file uploading is used, according to contexts:

6
doc/development/gitaly.md
View File

@ -73,12 +73,12 @@ when Gitaly is called more than 30 times in a single Rails request or Sidekiq ex
As a temporary measure, export `GITALY_DISABLE_REQUEST_LIMITS=1` to suppress the error. This disables the n+1 detection
in your development environment.
Please raise an issue in the GitLab CE or EE repositories to report the issue. Include the labels ~Gitaly
~performance ~"technical debt". Please ensure that the issue contains the full stack trace and error message of the
Raise an issue in the GitLab CE or EE repositories to report the issue. Include the labels ~Gitaly
~performance ~"technical debt". Ensure that the issue contains the full stack trace and error message of the
`TooManyInvocationsError`. Also include any known failing tests if possible.
Isolate the source of the n+1 problem. This is usually a loop that results in Gitaly being called for each
element in an array. If you are unable to isolate the problem, please contact a member
element in an array. If you are unable to isolate the problem, contact a member
of the [Gitaly Team](https://gitlab.com/groups/gl-gitaly/group_members) for assistance.
After the source has been found, wrap it in an `allow_n_plus_1_calls` block, as follows:

2
doc/development/gitpod_internals.md
View File

@ -19,7 +19,7 @@ The current settings are:
A webhook that starts with `https://gitpod.io/` is created to enable prebuilds (see [Enabling Prebuilds](https://www.gitpod.io/docs/configure/authentication/gitlab#enabling-prebuilds) for more details). The webhook is maintained by an [Engineering Productivity team](https://about.gitlab.com/handbook/engineering/quality/engineering-productivity/).
You can find this webhook in [Webhook Settings in `gitlab-org/gitlab`](https://gitlab.com/gitlab-org/gitlab/-/hooks). If you cannot access this setting, please chat to the [Engineering Productivity team](https://about.gitlab.com/handbook/engineering/quality/engineering-productivity/).
You can find this webhook in [Webhook Settings in `gitlab-org/gitlab`](https://gitlab.com/gitlab-org/gitlab/-/hooks). If you cannot access this setting, chat to the [Engineering Productivity team](https://about.gitlab.com/handbook/engineering/quality/engineering-productivity/).
### Troubleshooting a failed webhook

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

@ -26,7 +26,7 @@ can still have specifics. They are described in their respective
The Go upgrade documentation [provides an overview](go_upgrade.md#overview)
of how GitLab manages and ships Go binary support.
If a GitLab component requires a newer version of Go, please
If a GitLab component requires a newer version of Go,
follow the [upgrade process](go_upgrade.md#updating-go-version) to ensure no customer, team, or component is adversely impacted.
Sometimes, individual projects must also [manage builds with multiple versions of Go](go_upgrade.md#supporting-multiple-go-versions).

2
doc/development/gotchas.md
View File

@ -76,7 +76,7 @@ When run, this spec doesn't do what we might expect:
This is because FactoryBot sequences are not reset for each example.
Please remember that sequence-generated values exist only to avoid having to
Remember that sequence-generated values exist only to avoid having to
explicitly set attributes that have a uniqueness constraint when using a factory.
### Solution

2
doc/development/i18n/translation.md
View File

@ -96,7 +96,7 @@ For example, in German, the word _user_ can be translated into _Benutzer_ (male)
### Updating the glossary
To propose additions to the glossary, please
To propose additions to the glossary,
[open an issue](https://gitlab.com/gitlab-org/gitlab/-/issues?scope=all&utf8=✓&state=all&label_name[]=Category%3AInternationalization).
## French translation guidelines

8
doc/development/import_export.md
View File

@ -288,13 +288,13 @@ Fixtures used in Import/Export specs live in `spec/fixtures/lib/gitlab/import_ex
There are two versions of each of these fixtures:
- A human readable single JSON file with all objects, called either `project.json` or `group.json`.
- A folder named `tree`, containing a tree of files in `ndjson` format. **Please do not edit files under this folder manually unless strictly necessary.**
- A folder named `tree`, containing a tree of files in `ndjson` format. **Do not edit files under this folder manually unless strictly necessary.**
The tools to generate the NDJSON tree from the human-readable JSON files live in the [`gitlab-org/memory-team/team-tools`](https://gitlab.com/gitlab-org/memory-team/team-tools/-/blob/master/import-export/) project.
### Project
**Please use `legacy-project-json-to-ndjson.sh` to generate the NDJSON tree.**
**Use `legacy-project-json-to-ndjson.sh` to generate the NDJSON tree.**
The NDJSON tree looks like:
@ -328,7 +328,7 @@ tree
### Group
**Please use `legacy-group-json-to-ndjson.rb` to generate the NDJSON tree.**
**Use `legacy-group-json-to-ndjson.rb` to generate the NDJSON tree.**
The NDJSON tree looks like this:
@ -355,4 +355,4 @@ tree
```
WARNING:
When updating these fixtures, please ensure you update both `json` files and `tree` folder, as the tests apply to both.
When updating these fixtures, ensure you update both `json` files and `tree` folder, as the tests apply to both.

4
doc/development/integrations/secure_partner_integration.md
View File

@ -104,7 +104,7 @@ and complete an integration with the Secure stage.
- If you specified `remediations` in your artifact, it is proposed through our [remediation](../../user/application_security/vulnerabilities/index.md#resolve-a-vulnerability)
interface.
1. Demo the integration to GitLab:
- After you have tested and are ready to demo your integration please
- After you have tested and are ready to demo your integration,
[reach out](https://about.gitlab.com/partners/technology-partners/integrate/) to us. If you
skip this step you won't be able to do supported marketing.
1. Begin doing supported marketing of your GitLab integration.
@ -119,4 +119,4 @@ that may be helpful as part of this process. This covers various topics related
tool.
If you have any issues while working through your integration or the steps
above, please create an issue to discuss with us further.
above, create an issue to discuss with us further.

2
doc/development/internal_analytics/internal_event_instrumentation/migration.md
View File

@ -23,7 +23,7 @@ The event triggered by Internal Events has some special properties compared to p
1. The `label`, `property` and `value` attributes are not used within Internal Events and are always empty.
1. The `category` is automatically set to `InternalEventTracking`
Please make sure that you are okay with this change before you migrate and dashboards are changed accordingly.
Make sure that you are okay with this change before you migrate and dashboards are changed accordingly.
### Backend

4
doc/development/internal_analytics/internal_event_instrumentation/quick_start.md
View File

@ -44,7 +44,7 @@ Where:
## Trigger events
Triggering an event and thereby updating a metric is slightly different on backend and frontend. Please refer to the relevant section below.
Triggering an event and thereby updating a metric is slightly different on backend and frontend. Refer to the relevant section below.
### Backend tracking
@ -71,7 +71,7 @@ If a `project` but no `namespace` is provided, the `project.namespace` is used a
Any frontend tracking call automatically passes the values `user.id`, `namespace.id`, and `project.id` from the current context of the page.
If you need to pass any further properties, such as `extra`, `context`, `label`, `property`, and `value`, you can use the [deprecated snowplow implementation](https://docs.gitlab.com/16.4/ee/development/internal_analytics/snowplow/implementation.html). In this case, please let us know about your specific use-case in our [feedback issue for Internal Events](https://gitlab.com/gitlab-org/analytics-section/analytics-instrumentation/internal/-/issues/690).
If you need to pass any further properties, such as `extra`, `context`, `label`, `property`, and `value`, you can use the [deprecated snowplow implementation](https://docs.gitlab.com/16.4/ee/development/internal_analytics/snowplow/implementation.html). In this case, let us know about your specific use-case in our [feedback issue for Internal Events](https://gitlab.com/gitlab-org/analytics-section/analytics-instrumentation/internal/-/issues/690).
#### Vue components

6
doc/development/internal_analytics/metrics/metrics_lifecycle.md
View File

@ -24,7 +24,7 @@ As a result, if you need to change one of the following parts of a metric, you n
- **calculation logic**: This means any changes that can produce a different value than the previous implementation
- **YAML attributes**: The following attributes are directly used for analysis or calculation: `key_path`, `time_frame`, `value_type`, `data_source`.
If you change the `performance_indicator_type` attribute of a metric or think your case needs an exception from the outlined rules then please notify the Customer Success Ops team (`@csops-team`), Analytics Engineers (`@gitlab-data/analytics-engineers`), and Product Analysts (`@gitlab-data/product-analysts`) teams by `@` mentioning those groups in a comment on the merge request or issue.
If you change the `performance_indicator_type` attribute of a metric or think your case needs an exception from the outlined rules then notify the Customer Success Ops team (`@csops-team`), Analytics Engineers (`@gitlab-data/analytics-engineers`), and Product Analysts (`@gitlab-data/product-analysts`) teams by `@` mentioning those groups in a comment on the merge request or issue.
You can change any other attributes without impact to the calculation or analysis. See [this video tutorial](https://youtu.be/bYf3c01KCls) for help updating metric attributes.
@ -91,7 +91,7 @@ To remove a metric:
therefore continue to report the removed metric. The Analytics Instrumentation team
requires a record of all removed metrics to identify and filter them.
For example please take a look at this [merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60149/diffs#b01f429a54843feb22265100c0e4fec1b7da1240_10_10).
For example, take a look at this [merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60149/diffs#b01f429a54843feb22265100c0e4fec1b7da1240_10_10).
1. After you verify the metric can be safely removed,
remove the metric's instrumentation from
@ -99,7 +99,7 @@ To remove a metric:
or
[`ee/lib/ee/gitlab/usage_data.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/ee/gitlab/usage_data.rb).
For example please take a look at this [merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60149/diffs#6335dc533bd21df26db9de90a02dd66278c2390d_167_167).
For example, take a look at this [merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60149/diffs#6335dc533bd21df26db9de90a02dd66278c2390d_167_167).
1. Remove any other records related to the metric:
- The feature flag YAML file at [`config/feature_flags/*/*.yaml`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/config/feature_flags).

10
doc/development/labels/index.md
View File

@ -24,9 +24,9 @@ Most issues will have labels for at least one of the following:
- Priority: `~"priority::1"`, `~"priority::2"`, `~"priority::3"`, `~"priority::4"`
- Severity: `~"severity::1"`, `~"severity::2"`, `~"severity::3"`, `~"severity::4"`
Please add `~"breaking change"` label if the issue can be considered as a [breaking change](../deprecation_guidelines/index.md).
Add `~"breaking change"` label if the issue can be considered as a [breaking change](../deprecation_guidelines/index.md).
Please add `~security` label if the issue is related to application security.
Add `~security` label if the issue is related to application security.
All labels, their meaning and priority are defined on the
[labels page](https://gitlab.com/gitlab-org/gitlab/-/labels).
@ -252,7 +252,7 @@ We have the following priority labels:
- `~"priority::3"`
- `~"priority::4"`
Please refer to the issue triage [priority label](https://about.gitlab.com/handbook/engineering/quality/issue-triage/#priority) section in our handbook to see how it's used.
Refer to the issue triage [priority label](https://about.gitlab.com/handbook/engineering/quality/issue-triage/#priority) section in our handbook to see how it's used.
## Severity labels
@ -263,7 +263,7 @@ We have the following severity labels:
- `~"severity::3"`
- `~"severity::4"`
Please refer to the issue triage [severity label](https://about.gitlab.com/handbook/engineering/quality/issue-triage/#severity) section in our handbook to see how it's used.
Refer to the issue triage [severity label](https://about.gitlab.com/handbook/engineering/quality/issue-triage/#severity) section in our handbook to see how it's used.
## Label for community contributors
@ -301,7 +301,7 @@ with the [label `~"Community Challenge"`](https://gitlab.com/gitlab-org/gitlab/-
If your MR for the `~"Community Challenge"` issue gets merged, you will also have a chance to win a custom
GitLab merchandise.
If you've decided that you would like to work on an issue, please @-mention
If you've decided that you would like to work on an issue, @-mention
the [appropriate product manager](https://about.gitlab.com/handbook/product/#who-to-talk-to-for-what)
as soon as possible. The product manager will then pull in appropriate GitLab team
members to further discuss scope, design, and technical considerations. This will

4
doc/development/licensing.md
View File

@ -44,7 +44,7 @@ To tell License Finder about a dependency's license if it isn't auto-detected:
license_finder licenses add my_unknown_dependency MIT
```
For all of the above, please include `--why "Reason"` and `--who "My Name"` so the `decisions.yml` file can keep track of when, why, and who approved of a dependency.
For all of the above, include `--why "Reason"` and `--who "My Name"` so the `decisions.yml` file can keep track of when, why, and who approved of a dependency.
More detailed information on how the gem and its commands work is available in the [License Finder README](https://github.com/pivotal/LicenseFinder).
@ -77,4 +77,4 @@ Those projects are set to use a test license encryption key by default.
## Additional information
Please see the [Open Source](https://about.gitlab.com/handbook/engineering/open-source/#using-open-source-libraries) page for more information on licensing.
See the [Open Source](https://about.gitlab.com/handbook/engineering/open-source/#using-open-source-libraries) page for more information on licensing.

2
doc/development/logging.md
View File

@ -361,7 +361,7 @@ class MyExampleWorker
end
```
Please see [this example](https://gitlab.com/gitlab-org/gitlab/-/blob/16ecc33341a3f6b6bebdf78d863c5bce76b040d3/app/workers/ci/pipeline_artifacts/expire_artifacts_worker.rb#L20-21)
See [this example](https://gitlab.com/gitlab-org/gitlab/-/blob/16ecc33341a3f6b6bebdf78d863c5bce76b040d3/app/workers/ci/pipeline_artifacts/expire_artifacts_worker.rb#L20-21)
which logs a count of how many artifacts are destroyed per run of the `ExpireArtifactsWorker`.
## Exception Handling

4
doc/development/merge_request_concepts/performance.md
View File

@ -286,7 +286,7 @@ be clearly mentioned in the merge request description.
**Summary:** Iterating a single process to external services (for example, PostgreSQL, Redis, Object Storage)
should be executed in a **batch-style** to reduce connection overheads.
For fetching rows from various tables in a batch-style, please see [Eager Loading](#eager-loading) section.
For fetching rows from various tables in a batch-style, see [Eager Loading](#eager-loading) section.
### Example: Delete multiple files from Object Storage
@ -323,7 +323,7 @@ Using [`ReactiveCaching`](../utilities.md#reactivecaching) is one of the best so
transactions, otherwise it leads to severe contention problems
as an open transaction basically blocks the release of a PostgreSQL backend connection.
For keeping transaction as minimal as possible, please consider using `AfterCommitQueue`
For keeping transaction as minimal as possible, consider using `AfterCommitQueue`
module or `after_commit` AR hook.
Here is [an example](https://gitlab.com/gitlab-org/gitlab/-/issues/36154#note_247228859)

8
doc/development/migration_style_guide.md
View File

@ -27,7 +27,7 @@ When writing your migrations, also consider that databases might have stale data
or inconsistencies and guard for that. Try to make as few assumptions as
possible about the state of the database.
Please don't depend on GitLab-specific code since it can change in future
Don't depend on GitLab-specific code since it can change in future
versions. If needed copy-paste GitLab code into the migration to make it forward
compatible.
@ -140,7 +140,7 @@ Changes to the schema should be committed to `db/structure.sql`. This
file is automatically generated by Rails when you run
`bundle exec rails db:migrate`, so you typically should not
edit this file by hand. If your migration is adding a column to a
table, that column is added at the bottom. Please do not reorder
table, that column is added at the bottom. Do not reorder
columns manually for existing tables as this causes confusion to
other people using `db/structure.sql` generated by Rails.
@ -1025,7 +1025,7 @@ steps in the [database dictionary guide](database/database_dictionary.md#droppin
Dropping a database table is uncommon, and the `drop_table` method
provided by Rails is generally considered safe. Before dropping the table,
please consider the following:
consider the following:
If your table has foreign keys on a [high-traffic table](#high-traffic-tables) (like `projects`), then
the `DROP TABLE` statement is likely to stall concurrent traffic until it fails with **statement timeout** error.
@ -1370,7 +1370,7 @@ See the [Testing Rails migrations](testing_guide/testing_migrations_guide.md) st
## Data migration
Please prefer Arel and plain SQL over usual ActiveRecord syntax. In case of
Prefer Arel and plain SQL over usual ActiveRecord syntax. In case of
using plain SQL, you need to quote all input manually with `quote_string` helper.
Example with Arel:

2
doc/development/multi_version_compatibility.md
View File

@ -243,7 +243,7 @@ With all those details in mind, let's imagine we need to replace a query, and th
1. **contract**: from `Schema B` to `Schema C` (post-deployment migration). Nothing uses the old index anymore, we can safely remove it.
This is only an example. More complex migrations, especially when background migrations are needed may
require more than one milestone. For details please refer to our [migration style guide](migration_style_guide.md).
require more than one milestone. For details refer to our [migration style guide](migration_style_guide.md).
## Examples of previous incidents

6
doc/development/pipelines/index.md
View File

@ -105,7 +105,7 @@ In addition, there are a few circumstances where we would always run the full RS
#### Have you encountered a problem with backend predictive tests?
If so, please have a look at [the Engineering Productivity RUNBOOK on predictive tests](https://gitlab.com/gitlab-org/quality/engineering-productivity/team/-/blob/main/runbooks/predictive-tests.md) for instructions on how to act upon predictive tests issues. Additionally, if you identified any test selection gaps, please let `@gl-quality/eng-prod` know so that we can take the necessary steps to optimize test selections.
If so, have a look at [the Engineering Productivity RUNBOOK on predictive tests](https://gitlab.com/gitlab-org/quality/engineering-productivity/team/-/blob/main/runbooks/predictive-tests.md) for instructions on how to act upon predictive tests issues. Additionally, if you identified any test selection gaps, let `@gl-quality/eng-prod` know so that we can take the necessary steps to optimize test selections.
### Jest predictive jobs
@ -130,7 +130,7 @@ The `rules` definitions for full Jest tests are defined at `.frontend:rules:jest
#### Have you encountered a problem with frontend predictive tests?
If so, please have a look at [the Engineering Productivity RUNBOOK on predictive tests](https://gitlab.com/gitlab-org/quality/engineering-productivity/team/-/blob/main/runbooks/predictive-tests.md) for instructions on how to act upon predictive tests issues.
If so, have a look at [the Engineering Productivity RUNBOOK on predictive tests](https://gitlab.com/gitlab-org/quality/engineering-productivity/team/-/blob/main/runbooks/predictive-tests.md) for instructions on how to act upon predictive tests issues.
### Fork pipelines
@ -302,7 +302,7 @@ The intent is to ensure that a change doesn't introduce a failure after `gitlab-
#### What it is
This pipeline is also called [JiHu validation pipeline](https://about.gitlab.com/handbook/ceo/chief-of-staff-team/jihu-support/jihu-validation-pipelines.html),
and it's currently allowed to fail. When that happens, please follow
and it's currently allowed to fail. When that happens, follow
[What to do when the validation pipeline fails](https://about.gitlab.com/handbook/ceo/chief-of-staff-team/jihu-support/jihu-validation-pipelines.html#what-to-do-when-the-validation-pipeline-failed).
#### How we run it

8
doc/development/project_templates.md
View File

@ -8,11 +8,11 @@ info: "To determine the technical writer assigned to the Stage/Group associated
## Adding a new built-in project template
If you'd like to contribute a new built-in project template to be distributed with GitLab, please do the following:
If you'd like to contribute a new built-in project template to be distributed with GitLab, do the following:
1. Create a new public project with the project content you'd like to contribute in a namespace of your choosing. You can view a working example [here](https://gitlab.com/gitlab-org/project-templates/dotnetcore).
- Projects should be as simple as possible and free of any unnecessary assets or dependencies.
1. When the project is ready for review, please create a new issue in [GitLab](https://gitlab.com/gitlab-org/gitlab/issues) with a link to your project.
1. When the project is ready for review, create a new issue in [GitLab](https://gitlab.com/gitlab-org/gitlab/issues) with a link to your project.
- In your issue, `@` mention the relevant Backend Engineering Manager and Product Manager for the [Create:Source Code group](https://about.gitlab.com/handbook/product/categories/#source-code-group).
To make the project template available when creating a new project, the vendoring process will have to be completed:
@ -59,7 +59,7 @@ To make the project template available when creating a new project, the vendorin
Existing templates are available in the [project-templates](https://gitlab.com/gitlab-org/project-templates)
group.
To contribute a change, please open a merge request in the relevant project
To contribute a change, open a merge request in the relevant project
and mention `@gitlab-org/manage/import/backend` when you are ready for a review.
Then, if your merge request gets accepted, either open an issue on
@ -79,7 +79,7 @@ Complete the following steps to test the project template in your own GitLab Dev
## For GitLab team members
Please ensure the merge request has been reviewed by the Security Counterpart before merging.
Ensure the merge request has been reviewed by the Security Counterpart before merging.
To review a merge request which changes a vendored project template, run the `check-template-changes` script:

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

@ -19,7 +19,7 @@ These Rails Endpoints:
## Proof of concept period: Feedback Request
We are currently evaluating a new approach for documenting Rails endpoints. Please [check out the Feedback Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/411605) and feel free to share your thoughts, suggestions, or concerns. We appreciate your participation in helping us improve the documentation!
We are currently evaluating a new approach for documenting Rails endpoints. [Check out the Feedback Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/411605) and feel free to share your thoughts, suggestions, or concerns. We appreciate your participation in helping us improve the documentation!
## SAST Scanners

2
doc/development/ruby3_gotchas.md
View File

@ -150,7 +150,7 @@ We run automated detection for this warning in tests via `deprecation_toolkit`,
but it relies on the fact that `Kernel#warn` emits a warning, so stubbing out this call will effectively remove the call to warn, which means `deprecation_toolkit` will never see the deprecation warnings.
Stubbing out the implementation removes that warning, and we never pick it up, so the build is green.
Please refer to [issue 364099](https://gitlab.com/gitlab-org/gitlab/-/issues/364099) for more context.
Refer to [issue 364099](https://gitlab.com/gitlab-org/gitlab/-/issues/364099) for more context.
## Testing in `irb` and `rails console`

2
doc/development/search/advanced_search_migration_styleguide.md
View File

@ -425,7 +425,7 @@ being upgraded to, we do the following:
### Process for removing migrations
1. Select migrations that were marked as obsolete before the current major release
1. If the step above includes all obsolete migrations, please keep one last migration as a safeguard for customers with unapplied migrations
1. If the step above includes all obsolete migrations, keep one last migration as a safeguard for customers with unapplied migrations
1. Delete migration files and spec files for those migrations
1. Verify that there are no references of the migrations in the `.rubocop_todo/` directory.
1. Create a merge request and assign it to a team member from the global search team.

2
doc/development/sec/analyzer_development_guide.md
View File

@ -226,7 +226,7 @@ After the above steps have been completed, the automatic release process execute
### Steps to perform after releasing an analyzer
1. After a new version of the analyzer Docker image has been tagged and deployed, please test it with the corresponding test project.
1. After a new version of the analyzer Docker image has been tagged and deployed, test it with the corresponding test project.
1. Announce the release on the relevant group Slack channel. Example message:
> FYI I've just released `ANALYZER_NAME` `ANALYZER_VERSION`. `LINK_TO_RELEASE`

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

@ -71,7 +71,7 @@ For details on how GitLab processes the reports generated by the scanners, see
## CI/CD template development
While CI/CD templates are the responsibility of the Verify section, many are critical to the Sec Section's feature usage.
If you are working with CI/CD templates, please read the [development guide for GitLab CI/CD templates](../cicd/templates.md).
If you are working with CI/CD templates, read the [development guide for GitLab CI/CD templates](../cicd/templates.md).
## Importance of the primary identifier

9
doc/development/secure_coding_guidelines.md
View File

@ -14,17 +14,16 @@ goal of reducing the number of vulnerabilities released over time.
**Contributing**
If you would like to contribute to one of the existing documents, or add
guidelines for a new vulnerability type, please open an MR! Please try to
guidelines for a new vulnerability type, open an MR! Try to
include links to examples of the vulnerability found, and link to any resources
used in defined mitigations. If you have questions or when ready for a review,
please ping `gitlab-com/gl-security/appsec`.
used in defined mitigations. If you have questions or when ready for a review, ping `gitlab-com/gl-security/appsec`.
## Permissions
### Description
Application permissions are used to determine who can access what and what actions they can perform.
For more information about the permission model at GitLab, please see [the GitLab permissions guide](permissions.md) or the [EE docs on permissions](../../ee/user/permissions.md).
For more information about the permission model at GitLab, see [the GitLab permissions guide](permissions.md) or the [EE docs on permissions](../../ee/user/permissions.md).
### Impact
@ -340,7 +339,7 @@ The injected client-side code is executed on the victim's browser in the context
- potentially <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> [obtain the victim's session tokens](https://youtu.be/2VFavqfDS6w?t=739)
- perform actions that lead to data loss/theft or account takeover
Much of the impact is contingent upon the function of the application and the capabilities of the victim's session. For further impact possibilities, please check out [the beef project](https://beefproject.com/).
Much of the impact is contingent upon the function of the application and the capabilities of the victim's session. For further impact possibilities, check out [the beef project](https://beefproject.com/).
For a demonstration of the impact on GitLab with a realistic attack scenario, see [this video on the GitLab Unfiltered channel](https://www.youtube.com/watch?v=t4PzHNycoKo) (internal, it requires being logged in with the GitLab Unfiltered account).

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

@ -80,7 +80,7 @@ GitLab supports two deduplication strategies:
More [deduplication strategies have been suggested](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/195).
If you are implementing a worker that could benefit from a different
strategy, please comment in the issue.
strategy, comment in the issue.
#### Until Executing

2
doc/development/sql.md
View File

@ -86,7 +86,7 @@ _can_ be used by `ILIKE` / `LIKE` and can lead to greatly improved performance.
One downside of these indexes is that they can easily get quite large (depending
on the amount of data indexed).
To keep naming of these indexes consistent please use the following naming
To keep naming of these indexes consistent, use the following naming
pattern:
```plaintext

4
doc/development/testing_guide/best_practices.md
View File

@ -385,7 +385,7 @@ NOTE:
`stub_method` does not support method existence and method arity checks.
WARNING:
`stub_method` is supposed to be used in factories only. It's strongly discouraged to be used elsewhere. Please consider using [RSpec mocks](https://rspec.info/features/3-12/rspec-mocks/) if available.
`stub_method` is supposed to be used in factories only. It's strongly discouraged to be used elsewhere. Consider using [RSpec mocks](https://rspec.info/features/3-12/rspec-mocks/) if available.
#### Stubbing member access level
@ -582,7 +582,7 @@ Use the coverage reports to ensure your tests cover 100% of your code.
NOTE:
Before writing a new system test,
[please consider **not** writing one](testing_levels.md#consider-not-writing-a-system-test)!
[consider **not** writing one](testing_levels.md#consider-not-writing-a-system-test)!
- Feature specs should be named `ROLE_ACTION_spec.rb`, such as
`user_changes_password_spec.rb`.

2
doc/development/testing_guide/end_to_end/best_practices.md
View File

@ -361,7 +361,7 @@ When you add a new test that requires administrator access, apply the RSpec meta
When running tests locally or configuring a pipeline, the environment variable `QA_CAN_TEST_ADMIN_FEATURES` can be set to `false` to skip tests that have the `:requires_admin` tag.
NOTE:
If the _only_ action in the test that requires administrator access is to toggle a feature flag, please use the `feature_flag` tag instead. More details can be found in [testing with feature flags](feature_flags.md).
If the _only_ action in the test that requires administrator access is to toggle a feature flag, use the `feature_flag` tag instead. More details can be found in [testing with feature flags](feature_flags.md).
## Prefer `Commit` resource over `ProjectPush`

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