-
-
-
- {{
- s__(`mrWidget|The source branch HEAD has recently changed.
-Please reload the page and review the changes before merging`)
- }}
+
+
+
+ {{ $options.i18n.I18N_SHA_MISMATCH.warningMessage }}
+ {{ $options.i18n.I18N_SHA_MISMATCH.actionButtonLabel }}
diff --git a/app/assets/javascripts/vue_merge_request_widget/i18n.js b/app/assets/javascripts/vue_merge_request_widget/i18n.js
index e8e522a01e9..c88e795e5f3 100644
--- a/app/assets/javascripts/vue_merge_request_widget/i18n.js
+++ b/app/assets/javascripts/vue_merge_request_widget/i18n.js
@@ -5,3 +5,8 @@ export const SQUASH_BEFORE_MERGE = {
checkboxLabel: __('Squash commits'),
helpLabel: __('What is squashing?'),
};
+
+export const I18N_SHA_MISMATCH = {
+ warningMessage: __('Merge blocked: new changes were just added.'),
+ actionButtonLabel: __('Review changes'),
+};
diff --git a/app/assets/javascripts/vue_merge_request_widget/mr_widget_options.vue b/app/assets/javascripts/vue_merge_request_widget/mr_widget_options.vue
index 75e74e17182..a8a9df598f5 100644
--- a/app/assets/javascripts/vue_merge_request_widget/mr_widget_options.vue
+++ b/app/assets/javascripts/vue_merge_request_widget/mr_widget_options.vue
@@ -38,6 +38,7 @@ import RebaseState from './components/states/mr_widget_rebase.vue';
import NothingToMergeState from './components/states/nothing_to_merge.vue';
import PipelineFailedState from './components/states/pipeline_failed.vue';
import ReadyToMergeState from './components/states/ready_to_merge.vue';
+import ShaMismatch from './components/states/sha_mismatch.vue';
import UnresolvedDiscussionsState from './components/states/unresolved_discussions.vue';
import WorkInProgressState from './components/states/work_in_progress.vue';
// import ExtensionsContainer from './components/extensions/container';
@@ -72,7 +73,7 @@ export default {
'mr-widget-not-allowed': NotAllowedState,
'mr-widget-missing-branch': MissingBranchState,
'mr-widget-ready-to-merge': ReadyToMergeState,
- 'sha-mismatch': ReadyToMergeState,
+ 'sha-mismatch': ShaMismatch,
'mr-widget-checking': CheckingState,
'mr-widget-unresolved-discussions': UnresolvedDiscussionsState,
'mr-widget-pipeline-blocked': PipelineBlockedState,
diff --git a/app/controllers/import/available_namespaces_controller.rb b/app/controllers/import/available_namespaces_controller.rb
index c6211b33d28..0c2af13d3f3 100644
--- a/app/controllers/import/available_namespaces_controller.rb
+++ b/app/controllers/import/available_namespaces_controller.rb
@@ -4,6 +4,6 @@ class Import::AvailableNamespacesController < ApplicationController
feature_category :importers
def index
- render json: NamespaceSerializer.new.represent(current_user.manageable_groups_with_routes)
+ render json: NamespaceSerializer.new.represent(current_user.manageable_groups_with_routes(include_groups_with_developer_maintainer_access: true))
end
end
diff --git a/app/controllers/import/base_controller.rb b/app/controllers/import/base_controller.rb
index 1121ecfb65c..53856e4575b 100644
--- a/app/controllers/import/base_controller.rb
+++ b/app/controllers/import/base_controller.rb
@@ -11,8 +11,7 @@ class Import::BaseController < ApplicationController
format.json do
render json: { imported_projects: serialized_imported_projects,
provider_repos: serialized_provider_repos,
- incompatible_repos: serialized_incompatible_repos,
- namespaces: serialized_namespaces }
+ incompatible_repos: serialized_incompatible_repos }
end
format.html
end
@@ -74,14 +73,6 @@ class Import::BaseController < ApplicationController
@already_added_projects ||= filtered(find_already_added_projects(provider_name))
end
- def serialized_namespaces
- NamespaceSerializer.new.represent(namespaces)
- end
-
- def namespaces
- current_user.manageable_groups_with_routes
- end
-
# rubocop: disable CodeReuse/ActiveRecord
def find_already_added_projects(import_type)
current_user.created_projects.where(import_type: import_type).with_import_state
diff --git a/app/controllers/projects/pipelines_controller.rb b/app/controllers/projects/pipelines_controller.rb
index 1ee92009a76..e983fd9c993 100644
--- a/app/controllers/projects/pipelines_controller.rb
+++ b/app/controllers/projects/pipelines_controller.rb
@@ -12,12 +12,12 @@ class Projects::PipelinesController < Projects::ApplicationController
before_action :authorize_read_ci_cd_analytics!, only: [:charts]
before_action :authorize_create_pipeline!, only: [:new, :create, :config_variables]
before_action :authorize_update_pipeline!, only: [:retry, :cancel]
- before_action do
- push_frontend_feature_flag(:graphql_pipeline_details, project, type: :development, default_enabled: :yaml)
- push_frontend_feature_flag(:graphql_pipeline_details_users, current_user, type: :development, default_enabled: :yaml)
- end
before_action :ensure_pipeline, only: [:show, :downloadable_artifacts]
+ before_action do
+ push_frontend_feature_flag(:pipeline_source_filter, project, type: :development, default_enabled: :yaml)
+ end
+
# Will be removed with https://gitlab.com/gitlab-org/gitlab/-/issues/225596
before_action :redirect_for_legacy_scope_filter, only: [:index], if: -> { request.format.html? }
diff --git a/app/controllers/repositories/git_http_client_controller.rb b/app/controllers/repositories/git_http_client_controller.rb
index 76d9983d341..b3adda8c633 100644
--- a/app/controllers/repositories/git_http_client_controller.rb
+++ b/app/controllers/repositories/git_http_client_controller.rb
@@ -33,7 +33,7 @@ module Repositories
end
def authenticate_user
- @authentication_result = Gitlab::Auth::Result.new
+ @authentication_result = Gitlab::Auth::Result::EMPTY
if allow_basic_auth? && basic_auth_provided?
login, password = user_name_and_password(request)
diff --git a/app/experiments/application_experiment.rb b/app/experiments/application_experiment.rb
index 0dd829e259e..37d87baf30b 100644
--- a/app/experiments/application_experiment.rb
+++ b/app/experiments/application_experiment.rb
@@ -13,7 +13,7 @@ class ApplicationExperiment < Gitlab::Experiment # rubocop:disable Gitlab/Namesp
super
publish_to_client
- publish_to_database
+ publish_to_database if @record
end
def publish_to_client
@@ -25,7 +25,6 @@ class ApplicationExperiment < Gitlab::Experiment # rubocop:disable Gitlab/Namesp
end
def publish_to_database
- return unless @record
return unless should_track?
# if the context contains a namespace, group, project, user, or actor
diff --git a/app/models/projects/ci_feature_usage.rb b/app/models/projects/ci_feature_usage.rb
new file mode 100644
index 00000000000..a10426e50c9
--- /dev/null
+++ b/app/models/projects/ci_feature_usage.rb
@@ -0,0 +1,27 @@
+# frozen_string_literal: true
+
+module Projects
+ class CiFeatureUsage < ApplicationRecord
+ self.table_name = 'project_ci_feature_usages'
+
+ belongs_to :project
+
+ validates :project, :feature, presence: true
+
+ enum feature: {
+ code_coverage: 1,
+ security_report: 2
+ }
+
+ def self.insert_usage(project_id:, feature:, default_branch:)
+ insert(
+ {
+ project_id: project_id,
+ feature: feature,
+ default_branch: default_branch
+ },
+ unique_by: 'index_project_ci_feature_usages_unique_columns'
+ )
+ end
+ end
+end
diff --git a/app/services/ci/daily_build_group_report_result_service.rb b/app/services/ci/daily_build_group_report_result_service.rb
index 820e6e08fc5..25c6d57d961 100644
--- a/app/services/ci/daily_build_group_report_result_service.rb
+++ b/app/services/ci/daily_build_group_report_result_service.rb
@@ -3,7 +3,13 @@
module Ci
class DailyBuildGroupReportResultService
def execute(pipeline)
- DailyBuildGroupReportResult.upsert_reports(coverage_reports(pipeline))
+ if DailyBuildGroupReportResult.upsert_reports(coverage_reports(pipeline))
+ Projects::CiFeatureUsage.insert_usage(
+ project_id: pipeline.project_id,
+ feature: :code_coverage,
+ default_branch: pipeline.default_branch?
+ )
+ end
end
private
diff --git a/app/views/projects/pipelines/show.html.haml b/app/views/projects/pipelines/show.html.haml
index 1c134d914e9..30ebe4f20b6 100644
--- a/app/views/projects/pipelines/show.html.haml
+++ b/app/views/projects/pipelines/show.html.haml
@@ -5,9 +5,7 @@
- add_page_specific_style 'page_bundles/pipeline'
- add_page_specific_style 'page_bundles/reports'
- add_page_specific_style 'page_bundles/ci_status'
-
-- if Feature.enabled?(:graphql_pipeline_details, @project, default_enabled: :yaml) || Feature.enabled?(:graphql_pipeline_details_users, @current_user, default_enabled: :yaml)
- - add_page_startup_graphql_call('pipelines/get_pipeline_details', { projectPath: @project.full_path, iid: @pipeline.iid })
+- add_page_startup_graphql_call('pipelines/get_pipeline_details', { projectPath: @project.full_path, iid: @pipeline.iid })
.js-pipeline-container{ data: { controller_action: "#{controller.action_name}" } }
#js-pipeline-header-vue.pipeline-header-container{ data: { full_path: @project.full_path, pipeline_iid: @pipeline.iid, pipeline_id: @pipeline.id, pipelines_path: project_pipelines_path(@project) } }
diff --git a/config/feature_flags/development/graphql_pipeline_details.yml b/config/feature_flags/development/graphql_pipeline_details.yml
deleted file mode 100644
index 57b32c55da3..00000000000
--- a/config/feature_flags/development/graphql_pipeline_details.yml
+++ /dev/null
@@ -1,8 +0,0 @@
----
-name: graphql_pipeline_details
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/46380
-rollout_issue_url:
-type: development
-group: group::pipeline authoring
-default_enabled: true
-milestone: '13.6'
diff --git a/config/feature_flags/development/graphql_pipeline_details_users.yml b/config/feature_flags/development/graphql_pipeline_details_users.yml
deleted file mode 100644
index 97a2918bed5..00000000000
--- a/config/feature_flags/development/graphql_pipeline_details_users.yml
+++ /dev/null
@@ -1,8 +0,0 @@
----
-name: graphql_pipeline_details_users
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/52092
-rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/299112
-milestone: '13.9'
-type: development
-group: group::pipeline authoring
-default_enabled: false
diff --git a/db/migrate/20210812171704_create_project_ci_feature_usages.rb b/db/migrate/20210812171704_create_project_ci_feature_usages.rb
new file mode 100644
index 00000000000..376512bcb44
--- /dev/null
+++ b/db/migrate/20210812171704_create_project_ci_feature_usages.rb
@@ -0,0 +1,12 @@
+# frozen_string_literal: true
+
+class CreateProjectCiFeatureUsages < ActiveRecord::Migration[6.1]
+ def change
+ create_table :project_ci_feature_usages do |t|
+ t.references :project, index: false, foreign_key: { on_delete: :cascade }, null: false
+ t.integer :feature, null: false, limit: 2
+ t.boolean :default_branch, default: false, null: false
+ t.index [:project_id, :feature, :default_branch], unique: true, name: 'index_project_ci_feature_usages_unique_columns'
+ end
+ end
+end
diff --git a/db/migrate/20210816161107_remove_index_containing_faulty_regex.rb b/db/migrate/20210816161107_remove_index_containing_faulty_regex.rb
new file mode 100644
index 00000000000..d625ae6d13d
--- /dev/null
+++ b/db/migrate/20210816161107_remove_index_containing_faulty_regex.rb
@@ -0,0 +1,18 @@
+# frozen_string_literal: true
+
+class RemoveIndexContainingFaultyRegex < ActiveRecord::Migration[6.1]
+ include Gitlab::Database::MigrationHelpers
+
+ INDEX_NAME = "tmp_index_merge_requests_draft_and_status"
+
+ disable_ddl_transaction!
+
+ def up
+ remove_concurrent_index_by_name :merge_requests, INDEX_NAME
+ end
+
+ def down
+ # noop
+ #
+ end
+end
diff --git a/db/post_migrate/20210609202501_schedule_backfill_draft_status_on_merge_requests.rb b/db/post_migrate/20210609202501_schedule_backfill_draft_status_on_merge_requests.rb
index 72c4168af50..ed9a64c84ab 100644
--- a/db/post_migrate/20210609202501_schedule_backfill_draft_status_on_merge_requests.rb
+++ b/db/post_migrate/20210609202501_schedule_backfill_draft_status_on_merge_requests.rb
@@ -1,32 +1,13 @@
# frozen_string_literal: true
class ScheduleBackfillDraftStatusOnMergeRequests < ActiveRecord::Migration[6.1]
- include Gitlab::Database::MigrationHelpers
-
- INDEX_NAME = "tmp_index_merge_requests_draft_and_status"
- MIGRATION = 'BackfillDraftStatusOnMergeRequests'
- DELAY_INTERVAL = 2.minutes
- BATCH_SIZE = 100
-
- disable_ddl_transaction!
-
def up
- add_concurrent_index :merge_requests, :id,
- where: "draft = false AND state_id = 1 AND ((title)::text ~* '^\\[draft\\]|\\(draft\\)|draft:|draft|\\[WIP\\]|WIP:|WIP'::text)",
- name: INDEX_NAME
-
- eligible_mrs = Gitlab::BackgroundMigration::BackfillDraftStatusOnMergeRequests::MergeRequest.eligible
-
- queue_background_migration_jobs_by_range_at_intervals(
- eligible_mrs,
- MIGRATION,
- DELAY_INTERVAL,
- track_jobs: true,
- batch_size: BATCH_SIZE
- )
+ # noop
+ #
end
def down
- remove_concurrent_index_by_name :merge_requests, INDEX_NAME
+ # noop
+ #
end
end
diff --git a/db/post_migrate/20210806011811_schedule_backfill_draft_column_on_merge_requests_rerun.rb b/db/post_migrate/20210806011811_schedule_backfill_draft_column_on_merge_requests_rerun.rb
index c3403d6ba47..90bca79624d 100644
--- a/db/post_migrate/20210806011811_schedule_backfill_draft_column_on_merge_requests_rerun.rb
+++ b/db/post_migrate/20210806011811_schedule_backfill_draft_column_on_merge_requests_rerun.rb
@@ -1,24 +1,9 @@
# frozen_string_literal: true
class ScheduleBackfillDraftColumnOnMergeRequestsRerun < ActiveRecord::Migration[6.1]
- include Gitlab::Database::MigrationHelpers
-
- MIGRATION = 'BackfillDraftStatusOnMergeRequests'
- DELAY_INTERVAL = 2.minutes
- BATCH_SIZE = 50
-
- disable_ddl_transaction!
-
def up
- eligible_mrs = Gitlab::BackgroundMigration::BackfillDraftStatusOnMergeRequests::MergeRequest.eligible
-
- queue_background_migration_jobs_by_range_at_intervals(
- eligible_mrs,
- MIGRATION,
- DELAY_INTERVAL,
- track_jobs: true,
- batch_size: BATCH_SIZE
- )
+ # noop
+ #
end
def down
diff --git a/db/schema_migrations/20210812171704 b/db/schema_migrations/20210812171704
new file mode 100644
index 00000000000..2471f7cdd38
--- /dev/null
+++ b/db/schema_migrations/20210812171704
@@ -0,0 +1 @@
+7c62c47ebad110a343c1f9834ae34bd0fa2bad763025da06f911e127a7380542
\ No newline at end of file
diff --git a/db/schema_migrations/20210816161107 b/db/schema_migrations/20210816161107
new file mode 100644
index 00000000000..1b8ab5265b7
--- /dev/null
+++ b/db/schema_migrations/20210816161107
@@ -0,0 +1 @@
+1e4d0b062c8e43b1af37c6cf869f9c173248d7bf5451b4aa5468d48c1004b97c
\ No newline at end of file
diff --git a/db/structure.sql b/db/structure.sql
index 27c3ed52db4..c5ab3c943b3 100644
--- a/db/structure.sql
+++ b/db/structure.sql
@@ -16935,6 +16935,22 @@ CREATE SEQUENCE project_ci_cd_settings_id_seq
ALTER SEQUENCE project_ci_cd_settings_id_seq OWNED BY project_ci_cd_settings.id;
+CREATE TABLE project_ci_feature_usages (
+ id bigint NOT NULL,
+ project_id bigint NOT NULL,
+ feature smallint NOT NULL,
+ default_branch boolean DEFAULT false NOT NULL
+);
+
+CREATE SEQUENCE project_ci_feature_usages_id_seq
+ START WITH 1
+ INCREMENT BY 1
+ NO MINVALUE
+ NO MAXVALUE
+ CACHE 1;
+
+ALTER SEQUENCE project_ci_feature_usages_id_seq OWNED BY project_ci_feature_usages.id;
+
CREATE TABLE project_compliance_framework_settings (
project_id bigint NOT NULL,
framework_id bigint,
@@ -20649,6 +20665,8 @@ ALTER TABLE ONLY project_auto_devops ALTER COLUMN id SET DEFAULT nextval('projec
ALTER TABLE ONLY project_ci_cd_settings ALTER COLUMN id SET DEFAULT nextval('project_ci_cd_settings_id_seq'::regclass);
+ALTER TABLE ONLY project_ci_feature_usages ALTER COLUMN id SET DEFAULT nextval('project_ci_feature_usages_id_seq'::regclass);
+
ALTER TABLE ONLY project_compliance_framework_settings ALTER COLUMN project_id SET DEFAULT nextval('project_compliance_framework_settings_project_id_seq'::regclass);
ALTER TABLE ONLY project_custom_attributes ALTER COLUMN id SET DEFAULT nextval('project_custom_attributes_id_seq'::regclass);
@@ -22239,6 +22257,9 @@ ALTER TABLE ONLY project_auto_devops
ALTER TABLE ONLY project_ci_cd_settings
ADD CONSTRAINT project_ci_cd_settings_pkey PRIMARY KEY (id);
+ALTER TABLE ONLY project_ci_feature_usages
+ ADD CONSTRAINT project_ci_feature_usages_pkey PRIMARY KEY (id);
+
ALTER TABLE ONLY project_compliance_framework_settings
ADD CONSTRAINT project_compliance_framework_settings_pkey PRIMARY KEY (project_id);
@@ -24806,6 +24827,8 @@ CREATE UNIQUE INDEX index_project_auto_devops_on_project_id ON project_auto_devo
CREATE UNIQUE INDEX index_project_ci_cd_settings_on_project_id ON project_ci_cd_settings USING btree (project_id);
+CREATE UNIQUE INDEX index_project_ci_feature_usages_unique_columns ON project_ci_feature_usages USING btree (project_id, feature, default_branch);
+
CREATE INDEX index_project_compliance_framework_settings_on_framework_id ON project_compliance_framework_settings USING btree (framework_id);
CREATE INDEX index_project_compliance_framework_settings_on_project_id ON project_compliance_framework_settings USING btree (project_id);
@@ -25720,8 +25743,6 @@ CREATE INDEX tmp_idx_on_namespaces_delayed_project_removal ON namespaces USING b
CREATE INDEX tmp_index_approval_project_rules_scanners ON approval_project_rules USING gin (scanners) WHERE (scanners @> '{cluster_image_scanning}'::text[]);
-CREATE INDEX tmp_index_merge_requests_draft_and_status ON merge_requests USING btree (id) WHERE ((draft = false) AND (state_id = 1) AND ((title)::text ~* '^\[draft\]|\(draft\)|draft:|draft|\[WIP\]|WIP:|WIP'::text));
-
CREATE INDEX tmp_index_namespaces_empty_traversal_ids_with_child_namespaces ON namespaces USING btree (id) WHERE ((parent_id IS NOT NULL) AND (traversal_ids = '{}'::integer[]));
CREATE INDEX tmp_index_namespaces_empty_traversal_ids_with_root_namespaces ON namespaces USING btree (id) WHERE ((parent_id IS NULL) AND (traversal_ids = '{}'::integer[]));
@@ -27056,6 +27077,9 @@ ALTER TABLE ONLY epic_user_mentions
ALTER TABLE ONLY approver_groups
ADD CONSTRAINT fk_rails_1cdcbd7723 FOREIGN KEY (group_id) REFERENCES namespaces(id) ON DELETE CASCADE;
+ALTER TABLE ONLY project_ci_feature_usages
+ ADD CONSTRAINT fk_rails_1deedbf64b FOREIGN KEY (project_id) REFERENCES projects(id) ON DELETE CASCADE;
+
ALTER TABLE ONLY packages_tags
ADD CONSTRAINT fk_rails_1dfc868911 FOREIGN KEY (package_id) REFERENCES packages_packages(id) ON DELETE CASCADE;
diff --git a/doc/administration/geo/index.md b/doc/administration/geo/index.md
index 6afbf76ac94..7175d41abd8 100644
--- a/doc/administration/geo/index.md
+++ b/doc/administration/geo/index.md
@@ -193,11 +193,8 @@ This list of limitations only reflects the latest version of GitLab. If you are
- The **primary** site has to be online for OAuth login to happen. Existing sessions and Git are not affected. Support for the **secondary** site to use an OAuth provider independent from the primary is [being planned](https://gitlab.com/gitlab-org/gitlab/-/issues/208465).
- The installation takes multiple manual steps that together can take about an hour depending on circumstances. We are working on improving this experience. See [Omnibus GitLab issue #2978](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/2978) for details.
- Real-time updates of issues/merge requests (for example, via long polling) doesn't work on the **secondary** site.
-- [Selective synchronization](replication/configuration.md#selective-synchronization) applies only to files and repositories. Other datasets are replicated to the **secondary** site in full, making it inappropriate for use as an access control mechanism.
-- Object pools for forked project deduplication work only on the **primary** site, and are duplicated on the **secondary** site.
- GitLab Runners cannot register with a **secondary** site. Support for this is [planned for the future](https://gitlab.com/gitlab-org/gitlab/-/issues/3294).
-- Configuring Geo **secondary** sites to [use high-availability configurations of PostgreSQL](https://gitlab.com/groups/gitlab-org/-/epics/2536) is currently in **alpha** support.
-- [Selective synchronization](replication/configuration.md#selective-synchronization) only limits what repositories are replicated. The entire PostgreSQL data is still replicated. Selective synchronization is not built to accommodate compliance / export control use cases.
+- [Selective synchronization](replication/configuration.md#selective-synchronization) only limits what repositories and files are replicated. The entire PostgreSQL data is still replicated. Selective synchronization is not built to accommodate compliance / export control use cases.
### Limitations on replication/verification
diff --git a/doc/administration/geo/replication/datatypes.md b/doc/administration/geo/replication/datatypes.md
index 62b366e9a4a..a696e5410e5 100644
--- a/doc/administration/geo/replication/datatypes.md
+++ b/doc/administration/geo/replication/datatypes.md
@@ -32,7 +32,6 @@ verification methods:
| Git | Project repository | Geo with Gitaly | Gitaly Checksum |
| Git | Project wiki repository | Geo with Gitaly | Gitaly Checksum |
| Git | Project designs repository | Geo with Gitaly | Gitaly Checksum |
-| Git | Object pools for forked project deduplication | Geo with Gitaly | _Not implemented_ |
| Git | Project Snippets | Geo with Gitaly | Gitaly Checksum |
| Git | Personal Snippets | Geo with Gitaly | Gitaly Checksum |
| Git | Group wiki repository | Geo with Gitaly | _Not implemented_ |
@@ -69,6 +68,8 @@ or using LVM.
It requires no special file system and can work with NFS or a mounted Storage Appliance (there may be
performance limitations when using a remote file system).
+Geo will trigger garbage collection in Gitaly to [deduplicate forked repositories](../../../development/git_object_deduplication.md#git-object-deduplication-and-gitlab-geo) on Geo secondary sites.
+
Communication is done via Gitaly's own gRPC API. There are three possible ways of synchronization:
- Using regular Git clone/fetch from one Geo site to another (with special authentication).
@@ -186,7 +187,6 @@ successfully, you must replicate their data using some other means.
|[CI job artifacts (other than Job Logs)](../../../ci/pipelines/job_artifacts.md) | **Yes** (10.4) | [No](https://gitlab.com/gitlab-org/gitlab/-/issues/8923) | Via Object Storage provider if supported. Native Geo support (Beta). | Verified only manually using [Integrity Check Rake Task](../../raketasks/check.md) on both sites and comparing the output between them. |
|[CI Pipeline Artifacts](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/ci/pipeline_artifact.rb) | [**Yes** (13.11)](https://gitlab.com/gitlab-org/gitlab/-/issues/238464) | [**Yes** (13.11)](https://gitlab.com/gitlab-org/gitlab/-/issues/238464) | Via Object Storage provider if supported. Native Geo support (Beta). | Persists additional artifacts after a pipeline completes |
|[Job logs](../../job_logs.md) | **Yes** (10.4) | [No](https://gitlab.com/gitlab-org/gitlab/-/issues/8923) | Via Object Storage provider if supported. Native Geo support (Beta). | Verified only on transfer or manually using [Integrity Check Rake Task](../../raketasks/check.md) on both sites and comparing the output between them. |
-|[Object pools for forked project deduplication](../../../development/git_object_deduplication.md) | **Yes** | No | No | |
|[Container Registry](../../packages/container_registry.md) | **Yes** (12.3) | No | No | Disabled by default. See [instructions](docker_registry.md) to enable. |
|[Content in object storage (beta)](object_storage.md) | **Yes** (12.4) | [No](https://gitlab.com/gitlab-org/gitlab/-/issues/13845) | No | |
|[Infrastructure Registry for Terraform Module](../../../user/packages/terraform_module_registry/index.md) | **Yes** (14.0) | [**Yes**](#limitation-of-verification-for-files-in-object-storage) (14.0) | Via Object Storage provider if supported. Native Geo support (Beta). | Behind feature flag `geo_package_file_replication`, enabled by default. |
diff --git a/doc/ci/jobs/index.md b/doc/ci/jobs/index.md
index 0ed8b68c0ce..aa12e1181cb 100644
--- a/doc/ci/jobs/index.md
+++ b/doc/ci/jobs/index.md
@@ -168,7 +168,7 @@ for a single run of the manual job.
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/21767) in GitLab 11.4.
-When you do not want to run a job immediately, you can use the [`when:delayed`](../yaml/index.md#whendelayed) keyword to
+When you do not want to run a job immediately, you can use the [`when:delayed`](../jobs/job_control.md#run-a-job-after-a-delay) keyword to
delay a job's execution for a certain period.
This is especially useful for timed incremental rollout where new code is rolled out gradually.
diff --git a/doc/ci/jobs/job_control.md b/doc/ci/jobs/job_control.md
index 634214aedc3..b8b05426297 100644
--- a/doc/ci/jobs/job_control.md
+++ b/doc/ci/jobs/job_control.md
@@ -497,6 +497,120 @@ test:
- "README.md"
```
+## Create a job that must be run manually
+
+You can require that a job doesn't run unless a user starts it. This is called a **manual job**.
+You might want to use a manual job for something like deploying to production.
+
+To specify a job as manual, add [`when: manual`](../yaml/index.md#when) to the job
+in the `.gitlab-ci.yml` file.
+
+By default, manual jobs display as skipped when the pipeline starts.
+
+You can use [protected branches](../../user/project/protected_branches.md) to more strictly
+[protect manual deployments](#protect-manual-jobs) from being run by unauthorized users.
+
+### Types of manual jobs
+
+Manual jobs can be either optional or blocking:
+
+- **Optional**: The default setting for manual jobs.
+ - They have [`allow_failure: true`](../yaml/index.md#allow_failure) by default.
+ - The status does not contribute to the overall pipeline status. A pipeline can
+ succeed even if all of its manual jobs fail.
+- **Blocking**: An optional setting for manual jobs.
+ - Add `allow_failure: false` to the job configuration.
+ - The pipeline stops at the stage where the job is defined. To let the pipeline
+ continue running, [run the manual job](#run-a-manual-job).
+ - Merge requests in projects with [merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md)
+ enabled can't be merged with a blocked pipeline. Blocked pipelines show a status
+ of **blocked**.
+
+### Run a manual job
+
+To run a manual job, you must have permission to merge to the assigned branch.
+
+To run a manual job:
+
+1. Go to the pipeline, job, [environment](../environments/index.md#configure-manual-deployments),
+ or deployment view.
+1. Next to the manual job, select **Play** (**{play}**).
+
+### Protect manual jobs **(PREMIUM)**
+
+Use [protected environments](../environments/protected_environments.md)
+to define a list of users authorized to run a manual job. You can authorize only
+the users associated with a protected environment to trigger manual jobs, which can:
+
+- More precisely limit who can deploy to an environment.
+- Block a pipeline until an approved user "approves" it.
+
+To protect a manual job:
+
+1. Add an `environment` to the job. For example:
+
+ ```yaml
+ deploy_prod:
+ stage: deploy
+ script:
+ - echo "Deploy to production server"
+ environment:
+ name: production
+ url: https://example.com
+ when: manual
+ rules:
+ - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
+ ```
+
+1. In the [protected environments settings](../environments/protected_environments.md#protecting-environments),
+ select the environment (`production` in this example) and add the users, roles or groups
+ that are authorized to trigger the manual job to the **Allowed to Deploy** list. Only those in
+ this list can trigger this manual job, as well as GitLab administrators
+ who are always able to use protected environments.
+
+You can use protected environments with blocking manual jobs to have a list of users
+allowed to approve later pipeline stages. Add `allow_failure: false` to the protected
+manual job and the pipeline's next stages only run after the manual job is triggered
+by authorized users.
+
+## Run a job after a delay
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/51352) in GitLab 11.4.
+
+Use [`when: delayed`](../yaml/index.md#when) to execute scripts after a waiting period, or if you want to avoid
+jobs immediately entering the `pending` state.
+
+You can set the period with `start_in` keyword. The value of `start_in` is an elapsed time in seconds, unless a unit is
+provided. `start_in` must be less than or equal to one week. Examples of valid values include:
+
+- `'5'` (a value with no unit must be surrounded by single quotes)
+- `5 seconds`
+- `30 minutes`
+- `1 day`
+- `1 week`
+
+When a stage includes a delayed job, the pipeline doesn't progress until the delayed job finishes.
+You can use this keyword to insert delays between different stages.
+
+The timer of a delayed job starts immediately after the previous stage completes.
+Similar to other types of jobs, a delayed job's timer doesn't start unless the previous stage passes.
+
+The following example creates a job named `timed rollout 10%` that is executed 30 minutes after the previous stage completes:
+
+```yaml
+timed rollout 10%:
+ stage: deploy
+ script: echo 'Rolling out 10% ...'
+ when: delayed
+ start_in: 30 minutes
+```
+
+To stop the active timer of a delayed job, click the **{time-out}** (**Unschedule**) button.
+This job can no longer be scheduled to run automatically. You can, however, execute the job manually.
+
+To start a delayed job immediately, select **Play** (**{play}**).
+Soon GitLab Runner starts the job.
+
## Use predefined CI/CD variables to run jobs only in specific pipeline types
You can use [predefined CI/CD variables](../variables/predefined_variables.md) to choose
diff --git a/doc/ci/migration/circleci.md b/doc/ci/migration/circleci.md
index 968adf2e161..106f5b3d819 100644
--- a/doc/ci/migration/circleci.md
+++ b/doc/ci/migration/circleci.md
@@ -188,7 +188,7 @@ release-branch-workflow:
- testing
```
-Example of the same workflow using [`when: manual`](../yaml/index.md#whenmanual) in GitLab CI/CD:
+Example of the same workflow using [`when: manual`](../jobs/job_control.md#create-a-job-that-must-be-run-manually) in GitLab CI/CD:
```yaml
deploy_prod:
diff --git a/doc/ci/migration/jenkins.md b/doc/ci/migration/jenkins.md
index ea33932f1d6..1a987a0ce47 100644
--- a/doc/ci/migration/jenkins.md
+++ b/doc/ci/migration/jenkins.md
@@ -108,8 +108,8 @@ There are some high level differences between the products worth mentioning:
- The `.gitlab-ci.yml` file is checked in to the root of your repository, much like a Jenkinsfile, but
is in the YAML format (see [complete reference](../yaml/index.md)) instead of a Groovy DSL. It's most
analogous to the declarative Jenkinsfile format.
-- Manual approvals or gates can be set up as [`when:manual` jobs](../yaml/index.md#whenmanual). These can
- also leverage [`protected environments`](../yaml/index.md#protecting-manual-jobs)
+- Manual approvals or gates can be set up as [`when:manual` jobs](../jobs/job_control.md#create-a-job-that-must-be-run-manually). These can
+ also leverage [`protected environments`](../jobs/job_control.md#run-a-job-after-a-delay)
to control who is able to approve them.
- GitLab comes with a [container registry](../../user/packages/container_registry/index.md), and we recommend using
container images to set up your build environment. For example, set up one pipeline that builds your build environment
diff --git a/doc/ci/pipelines/index.md b/doc/ci/pipelines/index.md
index 0ccbac2ab2d..22f18235f99 100644
--- a/doc/ci/pipelines/index.md
+++ b/doc/ci/pipelines/index.md
@@ -206,7 +206,7 @@ For each `var` or `file_var`, a key and value are required.
### Add manual interaction to your pipeline
-Manual actions, configured using the [`when:manual`](../yaml/index.md#whenmanual) keyword,
+[Manual jobs](../jobs/job_control.md#create-a-job-that-must-be-run-manually),
allow you to require manual interaction before moving forward in the pipeline.
You can do this straight from the pipeline graph. Just click the play button
diff --git a/doc/ci/yaml/index.md b/doc/ci/yaml/index.md
index 46115529b53..293390b2c67 100644
--- a/doc/ci/yaml/index.md
+++ b/doc/ci/yaml/index.md
@@ -1887,8 +1887,8 @@ variables:
### `allow_failure`
Use `allow_failure` when you want to let a job fail without impacting the rest of the CI
-suite. The default value is `false`, except for [manual](#whenmanual) jobs that use
-the `when: manual` syntax.
+suite. The default value is `false`, except for [manual](../jobs/job_control.md#create-a-job-that-must-be-run-manually) jobs that use
+the [`when: manual`](#when) syntax.
In jobs that use [`rules:`](#rules), all jobs default to `allow_failure: false`,
*including* `when: manual` jobs.
@@ -1952,28 +1952,23 @@ test_job_2:
### `when`
-Use `when` to implement jobs that run in case of failure or despite the
-failure.
+Use `when` to configure the conditions for when jobs run. If not defined in a job,
+the default value is `when: on_success`.
-The valid values of `when` are:
+**Keyword type**: Job keyword. You can use it only as part of a job.
-1. `on_success` (default) - Execute job only when all jobs in earlier stages succeed,
- or are considered successful because they have `allow_failure: true`.
-1. `on_failure` - Execute job only when at least one job in an earlier stage fails.
-1. `always` - Execute job regardless of the status of jobs in earlier stages.
-1. `manual` - Execute job [manually](#whenmanual).
-1. `delayed` - [Delay the execution of a job](#whendelayed) for a specified duration.
- Added in GitLab 11.14.
-1. `never`:
- - With job [`rules`](#rules), don't execute job.
- - With [`workflow:rules`](#workflow), don't run pipeline.
+**Possible inputs**:
-In the following example, the script:
+- `on_success` (default): Run the job only when all jobs in earlier stages succeed
+ or have `allow_failure: true`.
+- `manual`: Run the job only when [triggered manually](../jobs/job_control.md#create-a-job-that-must-be-run-manually).
+- `always`: Run the job regardless of the status of jobs in earlier stages.
+- `on_failure`: Run the job only when at least one job in an earlier stage fails.
+- `delayed`: [Delay the execution of a job](../jobs/job_control.md#run-a-job-after-a-delay)
+ for a specified duration.
+- `never`: Don't run the job.
-1. Executes `cleanup_build_job` only when `build_job` fails.
-1. Always executes `cleanup_job` as the last step in pipeline regardless of
- success or failure.
-1. Executes `deploy_job` when you run it manually in the GitLab UI.
+**Example of `when`**:
```yaml
stages:
@@ -2012,116 +2007,26 @@ cleanup_job:
when: always
```
-#### `when:manual`
+In this example, the script:
-A manual job is a type of job that is not executed automatically and must be explicitly
-started by a user. You might want to use manual jobs for things like deploying to production.
+1. Executes `cleanup_build_job` only when `build_job` fails.
+1. Always executes `cleanup_job` as the last step in pipeline regardless of
+ success or failure.
+1. Executes `deploy_job` when you run it manually in the GitLab UI.
-To make a job manual, add `when: manual` to its configuration.
+**Additional details**:
-When the pipeline starts, manual jobs display as skipped and do not run automatically.
-They can be started from the pipeline, job, [environment](../environments/index.md#configure-manual-deployments),
-and deployment views.
+- In [GitLab 13.5](https://gitlab.com/gitlab-org/gitlab/-/issues/201938) and later, you
+ can use `when:manual` in the same job as [`trigger`](#trigger). In GitLab 13.4 and
+ earlier, using them together causes the error `jobs:#{job-name} when should be on_success, on_failure or always`.
+- The default behavior of `allow_failure` changes to `true` with `when: manual`.
+ However, if you use `when: manual` with [`rules`](#rules), `allow_failure` defaults
+ to `false`.
-Manual jobs can be either optional or blocking:
+**Related topics**:
-- **Optional**: Manual jobs have [`allow_failure: true](#allow_failure) set by default
- and are considered optional. The status of an optional manual job does not contribute
- to the overall pipeline status. A pipeline can succeed even if all its manual jobs fail.
-
-- **Blocking**: To make a blocking manual job, add `allow_failure: false` to its configuration.
- Blocking manual jobs stop further execution of the pipeline at the stage where the
- job is defined. To let the pipeline continue running, click **{play}** (play) on
- the blocking manual job.
-
- Merge requests in projects with [merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md)
- enabled can't be merged with a blocked pipeline. Blocked pipelines show a status
- of **blocked**.
-
-When you use [`rules:`](#rules), `allow_failure` defaults to `false`, including for manual jobs.
-
-To trigger a manual job, a user must have permission to merge to the assigned branch.
-You can use [protected branches](../../user/project/protected_branches.md) to more strictly
-[protect manual deployments](#protecting-manual-jobs) from being run by unauthorized users.
-
-In [GitLab 13.5](https://gitlab.com/gitlab-org/gitlab/-/issues/201938) and later, you
-can use `when:manual` in the same job as [`trigger`](#trigger). In GitLab 13.4 and
-earlier, using them together causes the error `jobs:#{job-name} when should be on_success, on_failure or always`.
-
-##### Protecting manual jobs **(PREMIUM)**
-
-Use [protected environments](../environments/protected_environments.md)
-to define a list of users authorized to run a manual job. You can authorize only
-the users associated with a protected environment to trigger manual jobs, which can:
-
-- More precisely limit who can deploy to an environment.
-- Block a pipeline until an approved user "approves" it.
-
-To protect a manual job:
-
-1. Add an `environment` to the job. For example:
-
- ```yaml
- deploy_prod:
- stage: deploy
- script:
- - echo "Deploy to production server"
- environment:
- name: production
- url: https://example.com
- when: manual
- rules:
- - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
- ```
-
-1. In the [protected environments settings](../environments/protected_environments.md#protecting-environments),
- select the environment (`production` in this example) and add the users, roles or groups
- that are authorized to trigger the manual job to the **Allowed to Deploy** list. Only those in
- this list can trigger this manual job, as well as GitLab administrators
- who are always able to use protected environments.
-
-You can use protected environments with blocking manual jobs to have a list of users
-allowed to approve later pipeline stages. Add `allow_failure: false` to the protected
-manual job and the pipeline's next stages only run after the manual job is triggered
-by authorized users.
-
-#### `when:delayed`
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/51352) in GitLab 11.4.
-
-Use `when: delayed` to execute scripts after a waiting period, or if you want to avoid
-jobs immediately entering the `pending` state.
-
-You can set the period with `start_in` keyword. The value of `start_in` is an elapsed time in seconds, unless a unit is
-provided. `start_in` must be less than or equal to one week. Examples of valid values include:
-
-- `'5'`
-- `5 seconds`
-- `30 minutes`
-- `1 day`
-- `1 week`
-
-When a stage includes a delayed job, the pipeline doesn't progress until the delayed job finishes.
-You can use this keyword to insert delays between different stages.
-
-The timer of a delayed job starts immediately after the previous stage completes.
-Similar to other types of jobs, a delayed job's timer doesn't start unless the previous stage passes.
-
-The following example creates a job named `timed rollout 10%` that is executed 30 minutes after the previous stage completes:
-
-```yaml
-timed rollout 10%:
- stage: deploy
- script: echo 'Rolling out 10% ...'
- when: delayed
- start_in: 30 minutes
-```
-
-To stop the active timer of a delayed job, click the **{time-out}** (**Unschedule**) button.
-This job can no longer be scheduled to run automatically. You can, however, execute the job manually.
-
-To start a delayed job immediately, click the **Play** button.
-Soon GitLab Runner picks up and starts the job.
+- `when` can be used with [`rules`](#rules) for more dynamic job control.
+- `when` can be used with [`workflow`](#workflow) to control when a pipeline can start.
### `environment`
@@ -2249,7 +2154,7 @@ In the above example, the `review_app` job deploys to the `review`
environment. A new `stop_review_app` job is listed under `on_stop`.
After the `review_app` job is finished, it triggers the
`stop_review_app` job based on what is defined under `when`. In this case,
-it is set to `manual`, so it needs a [manual action](#whenmanual) from
+it is set to `manual`, so it needs a [manual action](../jobs/job_control.md#create-a-job-that-must-be-run-manually) from
the GitLab UI to run.
Also in the example, `GIT_STRATEGY` is set to `none`. If the
@@ -3697,7 +3602,7 @@ view which job triggered a downstream pipeline. In the [pipeline graph](../pipel
hover over the downstream pipeline job.
In [GitLab 13.5](https://gitlab.com/gitlab-org/gitlab/-/issues/201938) and later, you
-can use [`when:manual`](#whenmanual) in the same job as `trigger`. In GitLab 13.4 and
+can use [`when:manual`](#when) in the same job as `trigger`. In GitLab 13.4 and
earlier, using them together causes the error `jobs:#{job-name} when should be on_success, on_failure or always`.
You [cannot start `manual` trigger jobs with the API](https://gitlab.com/gitlab-org/gitlab/-/issues/284086).
diff --git a/doc/development/cicd/index.md b/doc/development/cicd/index.md
index a5ab0faaadd..76c756b0e95 100644
--- a/doc/development/cicd/index.md
+++ b/doc/development/cicd/index.md
@@ -79,7 +79,7 @@ case the runner downloads them using a dedicated API endpoint.
Artifacts are stored in object storage, while metadata is kept in the database. An important example of artifacts
are reports (like JUnit, SAST, and DAST) which are parsed and rendered in the merge request.
-Job status transitions are not all automated. A user may run [manual jobs](../../ci/yaml/index.md#whenmanual), cancel a pipeline, retry
+Job status transitions are not all automated. A user may run [manual jobs](../../ci/jobs/job_control.md#create-a-job-that-must-be-run-manually), cancel a pipeline, retry
specific failed jobs or the entire pipeline. Anything that
causes a job to change status triggers `ProcessPipelineService`, as it's responsible for
tracking the status of the entire pipeline.
diff --git a/doc/development/documentation/index.md b/doc/development/documentation/index.md
index ebc07b72ec1..59a1b8c7b99 100644
--- a/doc/development/documentation/index.md
+++ b/doc/development/documentation/index.md
@@ -469,7 +469,7 @@ If you want to know the in-depth details, here's what's really happening:
The following GitLab features are used among others:
-- [Manual actions](../../ci/yaml/index.md#whenmanual)
+- [Manual jobs](../../ci/jobs/job_control.md#create-a-job-that-must-be-run-manually)
- [Multi project pipelines](../../ci/pipelines/multi_project_pipelines.md)
- [Review Apps](../../ci/review_apps/index.md)
- [Artifacts](../../ci/yaml/index.md#artifacts)
diff --git a/doc/install/docker.md b/doc/install/docker.md
index a6bc18bd374..7be97a1f2e6 100644
--- a/doc/install/docker.md
+++ b/doc/install/docker.md
@@ -119,9 +119,16 @@ sudo docker logs -f gitlab
After starting a container you can visit `gitlab.example.com` (or
`http://192.168.59.103` if you used boot2docker on macOS). It might take a while
before the Docker container starts to respond to queries.
-The very first time you visit GitLab, you will be asked to set up the admin
-password. After you change it, you can log in with username `root` and the
-password you set up.
+
+Visit the GitLab URL, and log in with username `root`
+and the password from the following command:
+
+```shell
+sudo docker exec -it gitlab grep 'Password:' /etc/gitlab/initial_root_password
+```
+
+NOTE:
+The password file will be automatically deleted in the first reconfigure run after 24 hours.
### Install GitLab using Docker Compose
diff --git a/doc/integration/jira/index.md b/doc/integration/jira/index.md
index ebc61b29c5b..febd9907028 100644
--- a/doc/integration/jira/index.md
+++ b/doc/integration/jira/index.md
@@ -19,7 +19,7 @@ in your GitLab project with any of your projects in Jira.
### Jira integration
-This integration connects one or more GitLab project to a Jira instance. The Jira instance
+This integration connects one or more GitLab projects to a Jira instance. The Jira instance
can be hosted by you or in [Atlassian cloud](https://www.atlassian.com/cloud).
The supported Jira versions are `v6.x`, `v7.x`, and `v8.x`.
@@ -83,26 +83,31 @@ If these features do not work as expected, it is likely due to a problem with th
### GitLab is unable to comment on a Jira issue
-Make sure that the Jira user you set up for the integration has the
-correct access permission to post comments on a Jira issue and also to transition
-the issue, if you'd like GitLab to also be able to do so.
+If GitLab cannot comment on Jira issues, make sure the Jira user you
+set up for the integration has permission to:
+
+- Post comments on a Jira issue.
+- Transition the Jira issue.
+
Jira issue references and update comments do not work if the GitLab issue tracker is disabled.
### GitLab is unable to close a Jira issue
-Make sure the `Transition ID` you set within the Jira settings matches the one
+Make sure the `Transition ID` you set in the Jira settings matches the one
your project needs to close an issue.
-Make sure that the Jira issue is not already marked as resolved; that is,
-the Jira issue resolution field is not set. (It should not be struck through in
-Jira lists.)
+Make sure that the Jira issue is not already marked as resolved. That is,
+the Jira issue resolution field is not set, and the issue is not struck through in
+Jira lists.
### CAPTCHA
-CAPTCHA may be triggered after several consecutive failed login attempts
+CAPTCHA may be triggered after several consecutive failed login attempts,
which may lead to a `401 unauthorized` error when testing your Jira integration.
If CAPTCHA has been triggered, you can't use Jira's REST API to
-authenticate with the Jira site. You need to log in to your Jira instance
+authenticate with the Jira site.
+
+To fix this error, sign in to your Jira instance
and complete the CAPTCHA.
## Third-party Jira integrations
diff --git a/doc/user/admin_area/custom_project_templates.md b/doc/user/admin_area/custom_project_templates.md
index 12d143b3a13..8c0586e5851 100644
--- a/doc/user/admin_area/custom_project_templates.md
+++ b/doc/user/admin_area/custom_project_templates.md
@@ -18,9 +18,13 @@ is created, based on the user's access permissions:
- Public projects can be selected by any signed-in user as a template for a new project,
if all enabled [project features](../project/settings/index.md#sharing-and-permissions)
- except for GitLab Pages are set to **Everyone With Access**.
+ except for **GitLab Pages** and **Security & Compliance** are set to **Everyone With Access**.
+ The same applies to internal projects.
- Private projects can be selected only by users who are members of the projects.
+The **Metrics Dashboard** is set to **Only Project Members** when you create a new project. Make
+sure you change it to **Everyone With Access** before making it a project template.
+
Repository and database information that are copied over to each new project are
identical to the data exported with the [GitLab Project Import/Export](../project/settings/import_export.md).
diff --git a/doc/user/application_security/dependency_scanning/index.md b/doc/user/application_security/dependency_scanning/index.md
index 0eb4d77a783..565b9c29934 100644
--- a/doc/user/application_security/dependency_scanning/index.md
+++ b/doc/user/application_security/dependency_scanning/index.md
@@ -49,6 +49,17 @@ If you have need of this, please explain why by filling out the survey [here](ht
## Supported languages and package managers
+Dependency Scanning automatically detects the languages used in the repository. All analyzers
+matching the detected languages are run. There is usually no need to customize the selection of
+analyzers. We recommend not specifying the analyzers so you automatically use the full selection
+for best coverage, avoiding the need to make adjustments when there are deprecations or removals.
+However, you can override the selection using the variable `DS_EXCLUDED_ANALYZERS`.
+
+The language detection relies on CI job [`rules`](../../../ci/yaml/index.md#rules) and searches a
+maximum of two directory levels from the repository's root. For example, the
+`gemnasium-dependency_scanning` job is enabled if a repository contains either a `Gemfile` or
+`api/Gemfile` file, but not if the only supported dependency file is `api/client/Gemfile`.
+
The following languages and dependency managers are supported: