Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
ffa2b5560a
commit
3889461be4
|
|
@ -203,7 +203,7 @@ export default {
|
|||
<div class="gl-flex gl-flex-wrap gl-items-center gl-gap-2 gl-whitespace-nowrap gl-pl-3">
|
||||
<gl-sprintf :message="__('From line %{line1} to %{line2}')">
|
||||
<template #line1>
|
||||
<div class="gl-mx-1 gl-flex gl-rounded-base gl-bg-strong">
|
||||
<div class="gl-mx-1 gl-flex gl-rounded-base gl-bg-subtle">
|
||||
<gl-button
|
||||
size="small"
|
||||
icon="dash"
|
||||
|
|
@ -230,7 +230,7 @@ export default {
|
|||
</div>
|
||||
</template>
|
||||
<template #line2>
|
||||
<div class="gl-ml-1 gl-flex gl-rounded-base gl-bg-strong">
|
||||
<div class="gl-ml-1 gl-flex gl-rounded-base gl-bg-subtle">
|
||||
<gl-button
|
||||
size="small"
|
||||
icon="dash"
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
import { s__ } from '~/locale';
|
||||
|
||||
export const BASE_IMPORT_TABLE_ROW_GRID_CLASSES = 'gl-grid-cols-[repeat(2,1fr),200px,200px]';
|
||||
|
||||
export const IMPORT_HISTORY_TABLE_STATUS = {
|
||||
inProgress: 'started',
|
||||
complete: 'finished',
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
<script>
|
||||
import { BASE_IMPORT_TABLE_ROW_GRID_CLASSES } from './constants';
|
||||
/**
|
||||
* Basic formatting component for import history table header.
|
||||
*
|
||||
|
|
@ -18,7 +19,7 @@ export default {
|
|||
},
|
||||
computed: {
|
||||
appliedGridClasses() {
|
||||
return this.gridClasses || 'gl-grid-cols-[repeat(2,1fr),200px,200px]';
|
||||
return this.gridClasses || BASE_IMPORT_TABLE_ROW_GRID_CLASSES;
|
||||
},
|
||||
},
|
||||
defaultClasses: 'gl-flex gl-flex-grow gl-items-center gl-gap-3 gl-font-bold',
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
<script>
|
||||
import { GlButton } from '@gitlab/ui';
|
||||
import { v4 as uuidv4 } from 'uuid';
|
||||
import { BASE_IMPORT_TABLE_ROW_GRID_CLASSES } from './constants';
|
||||
|
||||
/**
|
||||
* Basic formatting component for import history table rows.
|
||||
|
|
@ -35,11 +37,15 @@ export default {
|
|||
data() {
|
||||
return {
|
||||
expanded: false,
|
||||
uid: uuidv4(),
|
||||
};
|
||||
},
|
||||
computed: {
|
||||
appliedGridClasses() {
|
||||
return this.gridClasses || 'md:gl-grid-cols-[repeat(2,1fr),200px,200px]';
|
||||
return this.gridClasses || BASE_IMPORT_TABLE_ROW_GRID_CLASSES;
|
||||
},
|
||||
uniqueExpandedId() {
|
||||
return `expanded-section-${this.uid}`;
|
||||
},
|
||||
},
|
||||
methods: {
|
||||
|
|
@ -65,8 +71,11 @@ export default {
|
|||
<gl-button
|
||||
v-if="showToggle"
|
||||
size="small"
|
||||
category="tertiary"
|
||||
:aria-label="expanded ? __('Collapse') : __('Expand')"
|
||||
:icon="expanded ? 'chevron-down' : 'chevron-right'"
|
||||
:aria-expanded="expanded"
|
||||
:aria-controls="uniqueExpandedId"
|
||||
@click="toggleExpand"
|
||||
/>
|
||||
<div
|
||||
|
|
@ -100,7 +109,7 @@ export default {
|
|||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="gl-pt-5">
|
||||
<div :id="uniqueExpandedId" class="gl-pt-5">
|
||||
<div v-if="expanded" data-testid="import-history-table-row-expanded">
|
||||
<!-- @slot Optionally provide a nested row -->
|
||||
<slot name="nested-row"></slot>
|
||||
|
|
|
|||
|
|
@ -191,6 +191,9 @@
|
|||
}
|
||||
|
||||
.suggestion-added-input {
|
||||
@apply gl-border-1;
|
||||
@apply gl-border-section;
|
||||
|
||||
> code {
|
||||
display: block;
|
||||
margin-left: 120px;
|
||||
|
|
|
|||
|
|
@ -109,8 +109,9 @@
|
|||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: space-between;
|
||||
background-color: $gray-10;
|
||||
@apply gl-bg-section;
|
||||
@apply gl-border;
|
||||
@apply gl-border-section;
|
||||
border-radius: $gl-border-radius-base $gl-border-radius-base 0 0;
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -94,19 +94,6 @@ Gitlab::Database::Partitioning.register_tables(
|
|||
]
|
||||
)
|
||||
|
||||
# Enable partition management for the backfill table during merge_request_diff_files partitioning.
|
||||
# This way new partitions will be created as the trigger syncs new rows across to this table.
|
||||
#
|
||||
Gitlab::Database::Partitioning.register_tables(
|
||||
[
|
||||
{
|
||||
limit_connection_names: %i[main],
|
||||
table_name: 'merge_request_diff_files_99208b8fac',
|
||||
partitioned_column: :merge_request_diff_id, strategy: :int_range, partition_size: 200_000_000
|
||||
}
|
||||
]
|
||||
)
|
||||
|
||||
# Enable partition management for the backfill table during web_hook_logs partitioning.
|
||||
# This way new partitions will be created as the trigger syncs new rows across to this table.
|
||||
Gitlab::Database::Partitioning.register_tables(
|
||||
|
|
|
|||
|
|
@ -6,7 +6,9 @@ feature_categories:
|
|||
- code_review_workflow
|
||||
description: Temporary table for partitioning the main merge_request_diff_files table
|
||||
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/149181
|
||||
removed_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/179313
|
||||
milestone: '17.0'
|
||||
removed_in_milestone: '17.9'
|
||||
gitlab_schema: gitlab_main_cell
|
||||
desired_sharding_key:
|
||||
project_id:
|
||||
|
|
@ -18,3 +20,4 @@ desired_sharding_key:
|
|||
sharding_key: project_id
|
||||
belongs_to: merge_request_diff
|
||||
table_size: over_limit
|
||||
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class DropMergeRequestDiffFilesPartition < Gitlab::Database::Migration[2.2]
|
||||
Gitlab::Database::Migration[2.2]
|
||||
include Gitlab::Database::PartitioningMigrationHelpers
|
||||
|
||||
milestone '17.9'
|
||||
disable_ddl_transaction!
|
||||
|
||||
def up
|
||||
drop_partitioned_table_for('merge_request_diff_files')
|
||||
end
|
||||
|
||||
def down
|
||||
partition_table_by_int_range(
|
||||
'merge_request_diff_files',
|
||||
'merge_request_diff_id',
|
||||
partition_size: 200_000_000,
|
||||
primary_key: %w[merge_request_diff_id relative_order]
|
||||
)
|
||||
|
||||
add_column :merge_request_diff_files_99208b8fac, :project_id, :bigint
|
||||
end
|
||||
end
|
||||
|
|
@ -0,0 +1 @@
|
|||
e47acb862f06277a2761acadc3195c01cd9dbedf481ff7b45b0c275e26ca678c
|
||||
|
|
@ -890,67 +890,6 @@ $$;
|
|||
|
||||
COMMENT ON FUNCTION table_sync_function_29bc99d6db() IS 'Partitioning migration: table sync for web_hook_logs table';
|
||||
|
||||
CREATE FUNCTION table_sync_function_3f39f64fc3() RETURNS trigger
|
||||
LANGUAGE plpgsql
|
||||
AS $$
|
||||
BEGIN
|
||||
IF (TG_OP = 'DELETE') THEN
|
||||
DELETE FROM merge_request_diff_files_99208b8fac where "merge_request_diff_id" = OLD."merge_request_diff_id" AND "relative_order" = OLD."relative_order";
|
||||
ELSIF (TG_OP = 'UPDATE') THEN
|
||||
UPDATE merge_request_diff_files_99208b8fac
|
||||
SET "new_file" = NEW."new_file",
|
||||
"renamed_file" = NEW."renamed_file",
|
||||
"deleted_file" = NEW."deleted_file",
|
||||
"too_large" = NEW."too_large",
|
||||
"a_mode" = NEW."a_mode",
|
||||
"b_mode" = NEW."b_mode",
|
||||
"new_path" = NEW."new_path",
|
||||
"old_path" = NEW."old_path",
|
||||
"diff" = NEW."diff",
|
||||
"binary" = NEW."binary",
|
||||
"external_diff_offset" = NEW."external_diff_offset",
|
||||
"external_diff_size" = NEW."external_diff_size",
|
||||
"generated" = NEW."generated"
|
||||
WHERE merge_request_diff_files_99208b8fac."merge_request_diff_id" = NEW."merge_request_diff_id" AND merge_request_diff_files_99208b8fac."relative_order" = NEW."relative_order";
|
||||
ELSIF (TG_OP = 'INSERT') THEN
|
||||
INSERT INTO merge_request_diff_files_99208b8fac ("new_file",
|
||||
"renamed_file",
|
||||
"deleted_file",
|
||||
"too_large",
|
||||
"a_mode",
|
||||
"b_mode",
|
||||
"new_path",
|
||||
"old_path",
|
||||
"diff",
|
||||
"binary",
|
||||
"external_diff_offset",
|
||||
"external_diff_size",
|
||||
"generated",
|
||||
"merge_request_diff_id",
|
||||
"relative_order")
|
||||
VALUES (NEW."new_file",
|
||||
NEW."renamed_file",
|
||||
NEW."deleted_file",
|
||||
NEW."too_large",
|
||||
NEW."a_mode",
|
||||
NEW."b_mode",
|
||||
NEW."new_path",
|
||||
NEW."old_path",
|
||||
NEW."diff",
|
||||
NEW."binary",
|
||||
NEW."external_diff_offset",
|
||||
NEW."external_diff_size",
|
||||
NEW."generated",
|
||||
NEW."merge_request_diff_id",
|
||||
NEW."relative_order");
|
||||
END IF;
|
||||
RETURN NULL;
|
||||
|
||||
END
|
||||
$$;
|
||||
|
||||
COMMENT ON FUNCTION table_sync_function_3f39f64fc3() IS 'Partitioning migration: table sync for merge_request_diff_files table';
|
||||
|
||||
CREATE FUNCTION table_sync_function_686d6c7993() RETURNS trigger
|
||||
LANGUAGE plpgsql
|
||||
AS $$
|
||||
|
|
@ -4362,26 +4301,6 @@ CREATE TABLE merge_request_diff_commits_b5377a7a34 (
|
|||
)
|
||||
PARTITION BY RANGE (merge_request_diff_id);
|
||||
|
||||
CREATE TABLE merge_request_diff_files_99208b8fac (
|
||||
new_file boolean NOT NULL,
|
||||
renamed_file boolean NOT NULL,
|
||||
deleted_file boolean NOT NULL,
|
||||
too_large boolean NOT NULL,
|
||||
a_mode character varying NOT NULL,
|
||||
b_mode character varying NOT NULL,
|
||||
new_path text NOT NULL,
|
||||
old_path text NOT NULL,
|
||||
diff text,
|
||||
"binary" boolean,
|
||||
external_diff_offset integer,
|
||||
external_diff_size integer,
|
||||
generated boolean,
|
||||
merge_request_diff_id bigint NOT NULL,
|
||||
relative_order integer NOT NULL,
|
||||
project_id bigint
|
||||
)
|
||||
PARTITION BY RANGE (merge_request_diff_id);
|
||||
|
||||
CREATE TABLE p_batched_git_ref_updates_deletions (
|
||||
id bigint NOT NULL,
|
||||
project_id bigint NOT NULL,
|
||||
|
|
@ -28225,9 +28144,6 @@ ALTER TABLE ONLY merge_request_diff_commits
|
|||
ALTER TABLE ONLY merge_request_diff_details
|
||||
ADD CONSTRAINT merge_request_diff_details_pkey PRIMARY KEY (merge_request_diff_id);
|
||||
|
||||
ALTER TABLE ONLY merge_request_diff_files_99208b8fac
|
||||
ADD CONSTRAINT merge_request_diff_files_99208b8fac_pkey PRIMARY KEY (merge_request_diff_id, relative_order);
|
||||
|
||||
ALTER TABLE ONLY merge_request_diff_files
|
||||
ADD CONSTRAINT merge_request_diff_files_pkey PRIMARY KEY (merge_request_diff_id, relative_order);
|
||||
|
||||
|
|
@ -38253,8 +38169,6 @@ CREATE TRIGGER table_sync_trigger_b99eb6998c AFTER INSERT OR DELETE OR UPDATE ON
|
|||
|
||||
CREATE TRIGGER table_sync_trigger_bc3e7b56bd AFTER INSERT OR DELETE OR UPDATE ON ci_runner_machines FOR EACH ROW EXECUTE FUNCTION table_sync_function_e438f29263();
|
||||
|
||||
CREATE TRIGGER table_sync_trigger_cd362c20e2 AFTER INSERT OR DELETE OR UPDATE ON merge_request_diff_files FOR EACH ROW EXECUTE FUNCTION table_sync_function_3f39f64fc3();
|
||||
|
||||
CREATE TRIGGER tags_loose_fk_trigger AFTER DELETE ON tags REFERENCING OLD TABLE AS old_table FOR EACH STATEMENT EXECUTE FUNCTION insert_into_loose_foreign_keys_deleted_records();
|
||||
|
||||
CREATE TRIGGER trigger_01b3fc052119 BEFORE INSERT OR UPDATE ON approval_merge_request_rules FOR EACH ROW EXECUTE FUNCTION trigger_01b3fc052119();
|
||||
|
|
|
|||
|
|
@ -17,21 +17,8 @@ management [solutions page](https://about.gitlab.com/solutions/compliance/).
|
|||
|
||||
The [security features](../security/_index.md) in GitLab may also help you meet relevant compliance standards.
|
||||
|
||||
## Policy management
|
||||
|
||||
Organizations have unique policy requirements, either due to organizational
|
||||
standards or mandates from regulatory bodies. The following features help you
|
||||
define rules and policies to adhere to workflow requirements, separation of duties,
|
||||
and secure supply chain best practices:
|
||||
|
||||
| Feature | Instances | Groups | Projects | Description |
|
||||
|:--------------|:------------------|:--------------------|:-----------------------|:-------------------------------|
|
||||
| [Credentials inventory](credentials_inventory.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="dotted-circle" >}} No | {{< icon name="dotted-circle" >}} No | Keep track of the credentials used by all of the users in a GitLab instance. |
|
||||
| [Granular user roles<br/>and flexible permissions](../user/permissions.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | Manage access and permissions with five different user roles and settings for external users. Set permissions according to people's role, rather than either read or write access to a repository. Don't share the source code with people that only need access to the issue tracker. |
|
||||
| [Merge request approvals](../user/project/merge_requests/approvals/_index.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | Configure approvals required for merge requests. |
|
||||
| [Push rules](../user/project/repository/push_rules.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | Control pushes to your repositories. |
|
||||
| Separation of duties using<br/>[protected branches](../user/project/repository/branches/protected.md#require-code-owner-approval-on-a-protected-branch) and<br/>[custom CI/CD configuration paths](../ci/pipelines/settings.md#specify-a-custom-cicd-configuration-file) | {{< icon name="dotted-circle" >}} No | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes | Leverage the GitLab cross-project YAML configurations to define deployers of code and developers of code. See how to use this setup to define these roles in the [Separation of Duties deploy project](https://gitlab.com/guided-explorations/separation-of-duties-deploy/blob/master/README.md) and the [Separation of Duties project](https://gitlab.com/guided-explorations/separation-of-duties/blob/master/README.md). |
|
||||
| [Security policies](../user/application_security/policies/_index.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | Configure customizable policies that require merge request approval based on policy rules, or enforce security scanners to execute in project pipelines for compliance requirements. Policies can be enforced granularly against specific projects, or all projects in a group or subgroup. |
|
||||
For more information on all GitLab compliance features to ensure your GitLab group meets common compliance standards, see
|
||||
[Compliance features](../user/compliance/_index.md).
|
||||
|
||||
## Compliant workflow automation
|
||||
|
||||
|
|
@ -43,11 +30,9 @@ settings and automation to ensure that whatever a compliance team has configured
|
|||
stays configured and working correctly. These features can help you automate
|
||||
compliance:
|
||||
|
||||
| Feature | Instances | Groups | Projects | Description |
|
||||
|:------------------------------------------------------------------------------------|:-----------------------|:-----------------------|:-----------------------|:-------------------------------------------------------------------------------------------|
|
||||
| [Compliance frameworks](../user/group/compliance_frameworks.md) | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes | {{< icon name="dotted-circle" >}} No | Describe the type of compliance requirements projects must follow. |
|
||||
| [Compliance pipelines](../user/group/compliance_pipelines.md) | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes | {{< icon name="dotted-circle" >}} No | Define a pipeline configuration to run for any projects with a given compliance framework. |
|
||||
| [Merge request approval policy approval settings](../user/application_security/policies/merge_request_approval_policies.md#approval_settings) | {{< icon name="dotted-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | {{< icon name="dotted-circle" >}} Yes | Enforce a merge request approval policy enforcing multiple approvers and override various project settings in all enforced groups or projects across your GitLab instance or group. |
|
||||
| Feature | Instances | Groups | Projects | Description |
|
||||
|:----------------------------------------------------------------------------------------------------------------------------------------------|:--------------------------------------|:-------------------------------------|:--------------------------------------|:------------|
|
||||
| [Merge request approval policy approval settings](../user/application_security/policies/merge_request_approval_policies.md#approval_settings) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | Enforce a merge request approval policy enforcing multiple approvers and override various project settings in all enforced groups or projects across your GitLab instance or group. |
|
||||
|
||||
## Audit management
|
||||
|
||||
|
|
@ -60,26 +45,38 @@ summary lists of audit data. Between these two, compliance teams can quickly
|
|||
identify if problems exist and then drill down into the specifics of those issues.
|
||||
These features can help provide visibility into GitLab and audit what is happening:
|
||||
|
||||
| Feature | Instances | Groups | Projects | Description |
|
||||
|:-------------------------------------------------------------------|:-----------------------|:-----------------------|:-----------------------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| [Audit events](audit_event_reports.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | To maintain the integrity of your code, audit events give administrators the ability to view any modifications made in the GitLab server in an advanced audit events system, so you can control, analyze, and track every change. |
|
||||
| [Audit reports](audit_event_reports.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | Create and access reports based on the audit events that have occurred. Use pre-built GitLab reports or the API to build your own. |
|
||||
| [Auditor users](auditor_users.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="dotted-circle" >}} No | {{< icon name="dotted-circle" >}} No | Auditor users are users who are given read-only access to all projects, groups, and other resources on the GitLab instance. |
|
||||
| [Compliance center](../user/compliance/compliance_center/_index.md) | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | Quickly get visibility into the compliance posture of your organization through compliance standards adherence reporting and violations reports. Manage your groups compliance frameworks centrally. |
|
||||
| Feature | Instances | Groups | Projects | Description |
|
||||
|:---------------------------------------------------------|:-------------------------------------|:-------------------------------------|:-------------------------------------|:------------|
|
||||
| [Audit events](audit_event_reports.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | To maintain the integrity of your code, audit events give administrators the ability to view any modifications made in the GitLab server in an advanced audit events system, so you can control, analyze, and track every change. |
|
||||
| [Audit reports](audit_event_reports.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | Create and access reports based on the audit events that have occurred. Use pre-built GitLab reports or the API to build your own. |
|
||||
| [Audit event streaming](audit_event_streaming/_index.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | Stream GitLab audit events to a HTTP endpoint or third party service, such as AWS S3 or GCP Logging. |
|
||||
| [Auditor users](auditor_users.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="dotted-circle" >}} No | {{< icon name="dotted-circle" >}} No | Auditor users are users who are given read-only access to all projects, groups, and other resources on the GitLab instance. |
|
||||
|
||||
## Policy management
|
||||
|
||||
Organizations have unique policy requirements, either due to organizational
|
||||
standards or mandates from regulatory bodies. The following features help you
|
||||
define rules and policies to adhere to workflow requirements, separation of duties,
|
||||
and secure supply chain best practices:
|
||||
|
||||
| Feature | Instances | Groups | Projects | Description |
|
||||
|:------------------------------------------------------------------------------|:-------------------------------------|:-------------------------------------|:-------------------------------------|:------------|
|
||||
| [Credentials inventory](credentials_inventory.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="dotted-circle" >}} No | {{< icon name="dotted-circle" >}} No | Keep track of the credentials used by all of the users in a GitLab instance. |
|
||||
| [Granular user roles<br/>and flexible permissions](../user/permissions.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | Manage access and permissions with five different user roles and settings for external users. Set permissions according to people's role, rather than either read or write access to a repository. Don't share the source code with people that only need access to the issue tracker. |
|
||||
| [Merge request approvals](../user/project/merge_requests/approvals/_index.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | Configure approvals required for merge requests. |
|
||||
| [Push rules](../user/project/repository/push_rules.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | Control pushes to your repositories. |
|
||||
| [Security policies](../user/application_security/policies/_index.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | Configure customizable policies that require merge request approval based on policy rules, or enforce security scanners to execute in project pipelines for compliance requirements. Policies can be enforced granularly against specific projects, or all projects in a group or subgroup. |
|
||||
|
||||
## Other compliance features
|
||||
|
||||
These features can also help with compliance requirements:
|
||||
|
||||
| Feature | Instances | Groups | Projects | Description |
|
||||
|:------------------------------------------------------------------------------------------------------------------------------------|:-----------------------|:-----------------------|:-----------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| [Email all users of a project,<br/>group, or entire server](email_from_gitlab.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="dotted-circle" >}} No | {{< icon name="dotted-circle" >}} No | Email groups of users based on project or group membership, or email everyone using the GitLab instance. These emails are great for scheduled maintenance or upgrades. |
|
||||
| [Enforce ToS acceptance](settings/terms.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="dotted-circle" >}} No | {{< icon name="dotted-circle" >}} No | Enforce your users accepting new terms of service by blocking GitLab traffic. |
|
||||
| [External Status Checks](../user/project/merge_requests/status_checks.md) | {{< icon name="dotted-circle" >}} No | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes | Interface with third-party systems you already use during development to ensure you remain compliant. |
|
||||
| [Generate reports on permission<br/>levels of users](admin_area.md#user-permission-export) | {{< icon name="check-circle" >}} Yes | {{< icon name="dotted-circle" >}} No | {{< icon name="dotted-circle" >}} No | Generate a report listing all users' access permissions for groups and projects in the instance. |
|
||||
| [License approval policies](../user/compliance/license_approval_policies.md) | {{< icon name="dotted-circle" >}} No | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes | Search dependencies for their licenses. This lets you determine if the licenses of your project's dependencies are compatible with your project's license. |
|
||||
| [Lock project membership to group](../user/group/access_and_permissions.md#prevent-members-from-being-added-to-projects-in-a-group) | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes | {{< icon name="dotted-circle" >}} No | Group owners can prevent new members from being added to projects in a group. |
|
||||
| [LDAP group sync](auth/ldap/ldap_synchronization.md#group-sync) | {{< icon name="check-circle" >}} Yes | {{< icon name="dotted-circle" >}} No | {{< icon name="dotted-circle" >}} No | Automatically synchronize groups and manage SSH keys, permissions, and authentication, so you can focus on building your product, not configuring your tools. |
|
||||
| [LDAP group sync filters](auth/ldap/ldap_synchronization.md#group-sync) | {{< icon name="check-circle" >}} Yes | {{< icon name="dotted-circle" >}} No | {{< icon name="dotted-circle" >}} No | Gives more flexibility to synchronize with LDAP based on filters, meaning you can leverage LDAP attributes to map GitLab permissions. |
|
||||
| [Linux package installations support<br/>log forwarding](https://docs.gitlab.com/omnibus/settings/logs.html#udp-log-forwarding) | {{< icon name="check-circle" >}} Yes | {{< icon name="dotted-circle" >}} No | {{< icon name="dotted-circle" >}} No | Forward your logs to a central system. |
|
||||
| [Restrict SSH Keys](../security/ssh_keys_restrictions.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="dotted-circle" >}} No | {{< icon name="dotted-circle" >}} No | Control the technology and key length of SSH keys used to access GitLab. |
|
||||
| Feature | Instances | Groups | Projects | Description |
|
||||
|:--------------------------------------------------------------------------------------------------------------------------------|:-------------------------------------|:-------------------------------------|:-------------------------------------|:------------|
|
||||
| [Email all users of a project,<br/>group, or entire server](email_from_gitlab.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="dotted-circle" >}} No | {{< icon name="dotted-circle" >}} No | Email groups of users based on project or group membership, or email everyone using the GitLab instance. These emails are great for scheduled maintenance or upgrades. |
|
||||
| [Enforce ToS acceptance](settings/terms.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="dotted-circle" >}} No | {{< icon name="dotted-circle" >}} No | Enforce your users accepting new terms of service by blocking GitLab traffic. |
|
||||
| [Generate reports on permission<br/>levels of users](admin_area.md#user-permission-export) | {{< icon name="check-circle" >}} Yes | {{< icon name="dotted-circle" >}} No | {{< icon name="dotted-circle" >}} No | Generate a report listing all users' access permissions for groups and projects in the instance. |
|
||||
| [LDAP group sync](auth/ldap/ldap_synchronization.md#group-sync) | {{< icon name="check-circle" >}} Yes | {{< icon name="dotted-circle" >}} No | {{< icon name="dotted-circle" >}} No | Automatically synchronize groups and manage SSH keys, permissions, and authentication, so you can focus on building your product, not configuring your tools. |
|
||||
| [LDAP group sync filters](auth/ldap/ldap_synchronization.md#group-sync) | {{< icon name="check-circle" >}} Yes | {{< icon name="dotted-circle" >}} No | {{< icon name="dotted-circle" >}} No | Gives more flexibility to synchronize with LDAP based on filters, meaning you can leverage LDAP attributes to map GitLab permissions. |
|
||||
| [Linux package installations support<br/>log forwarding](https://docs.gitlab.com/omnibus/settings/logs.html#udp-log-forwarding) | {{< icon name="check-circle" >}} Yes | {{< icon name="dotted-circle" >}} No | {{< icon name="dotted-circle" >}} No | Forward your logs to a central system. |
|
||||
| [Restrict SSH Keys](../security/ssh_keys_restrictions.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="dotted-circle" >}} No | {{< icon name="dotted-circle" >}} No | Control the technology and key length of SSH keys used to access GitLab. |
|
||||
|
|
|
|||
|
|
@ -12,14 +12,69 @@ title: Compliance
|
|||
|
||||
{{< /details >}}
|
||||
|
||||
The compliance tools provided by GitLab help you keep an eye on various aspects of your project, including:
|
||||
GitLab compliance features ensure your GitLab group meets common compliance standards, and are available at various pricing tiers. For more information about compliance management, see the compliance
|
||||
management [solutions page](https://about.gitlab.com/solutions/compliance/).
|
||||
|
||||
- [Compliance center](compliance_center/_index.md).
|
||||
- [Audit events](audit_events.md).
|
||||
- [Compliance frameworks](../group/compliance_frameworks.md).
|
||||
- [Policies](../application_security/policies/_index.md).
|
||||
- [License approval policies](license_approval_policies.md).
|
||||
- [License scanning of CycloneDX files](license_scanning_of_cyclonedx_files/_index.md).
|
||||
The [security features](../../security/_index.md) in GitLab may also help you meet relevant compliance standards.
|
||||
|
||||
For more information on all GitLab compliance features to ensure your GitLab instance meets common compliance standards, see
|
||||
[Compliance features](../../administration/compliance.md).
|
||||
|
||||
## Compliant workflow automation
|
||||
|
||||
It is important for compliance teams to be confident that their controls and
|
||||
requirements are set up correctly, but also that they _stay_ set up correctly.
|
||||
One way of doing this is manually checking settings periodically, but this is
|
||||
error prone and time consuming. A better approach is to use single-source-of-truth
|
||||
settings and automation to ensure that whatever a compliance team has configured,
|
||||
stays configured and working correctly. These features can help you automate
|
||||
compliance:
|
||||
|
||||
| Feature | Instances | Groups | Projects | Description |
|
||||
|:-----------------------------------------------------------------------------------------------------------------------------------------|:-------------------------------------|:-------------------------------------|:-------------------------------------|:------------|
|
||||
| [Compliance frameworks](../group/compliance_frameworks.md) | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes | {{< icon name="dotted-circle" >}} No | Describe the type of compliance requirements projects must follow. |
|
||||
| [Compliance pipelines](../group/compliance_pipelines.md) | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes | {{< icon name="dotted-circle" >}} No | Define a pipeline configuration to run for any projects with a given compliance framework. |
|
||||
| [Merge request approval policy approval settings](../application_security/policies/merge_request_approval_policies.md#approval_settings) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | Enforce a merge request approval policy enforcing multiple approvers and override various project settings in all enforced groups or projects across your GitLab instance or group. |
|
||||
|
||||
## Audit management
|
||||
|
||||
An important part of any compliance program is being able to go back and understand
|
||||
what happened, when it happened, and who was responsible. You can use this in audit
|
||||
situations as well as for understanding the root cause of issues when they occur.
|
||||
|
||||
It is helpful to have both low-level, raw lists of audit data as well as high-level,
|
||||
summary lists of audit data. Between these two, compliance teams can quickly
|
||||
identify if problems exist and then drill down into the specifics of those issues.
|
||||
These features can help provide visibility into GitLab and audit what is happening:
|
||||
|
||||
| Feature | Instances | Groups | Projects | Description |
|
||||
|:--------------------------------------------------|:-------------------------------------|:-------------------------------------|:-------------------------------------|:------------|
|
||||
| [Audit events](audit_events.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | To maintain the integrity of your code, audit events give administrators the ability to view any modifications made in the GitLab server in an advanced audit events system, so you can control, analyze, and track every change. |
|
||||
| [Audit reports](audit_events.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | Create and access reports based on the audit events that have occurred. Use pre-built GitLab reports or the API to build your own. |
|
||||
| [Audit event streaming](audit_event_streaming.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | Stream GitLab audit events to a HTTP endpoint or third party service, such as AWS S3 or GCP Logging. |
|
||||
| [Compliance center](compliance_center/_index.md) | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | Quickly get visibility into the compliance posture of your organization through compliance standards adherence reporting and violations reports. Manage your groups compliance frameworks centrally. |
|
||||
|
||||
## Policy management
|
||||
|
||||
Organizations have unique policy requirements, either due to organizational
|
||||
standards or mandates from regulatory bodies. The following features help you
|
||||
define rules and policies to adhere to workflow requirements, separation of duties,
|
||||
and secure supply chain best practices:
|
||||
|
||||
| Feature | Instances | Groups | Projects | Description |
|
||||
|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-------------------------------------|:-------------------------------------|:-------------------------------------|:------------|
|
||||
| [Granular user roles<br/>and flexible permissions](../permissions.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | Manage access and permissions with five different user roles and settings for external users. Set permissions according to people's role, rather than either read or write access to a repository. Don't share the source code with people that only need access to the issue tracker. |
|
||||
| [Merge request approvals](../project/merge_requests/approvals/_index.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | Configure approvals required for merge requests. |
|
||||
| [Push rules](../project/repository/push_rules.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | Control pushes to your repositories. |
|
||||
| Separation of duties using<br/>[protected branches](../project/repository/branches/protected.md#require-code-owner-approval-on-a-protected-branch) and<br/>[custom CI/CD configuration paths](../../ci/pipelines/settings.md#specify-a-custom-cicd-configuration-file) | {{< icon name="dotted-circle" >}} No | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes | Leverage the GitLab cross-project YAML configurations to define deployers of code and developers of code. See how to use this setup to define these roles in the [Separation of Duties deploy project](https://gitlab.com/guided-explorations/separation-of-duties-deploy/blob/master/README.md) and the [Separation of Duties project](https://gitlab.com/guided-explorations/separation-of-duties/blob/master/README.md). |
|
||||
| [Security policies](../application_security/policies/_index.md) | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | {{< icon name="check-circle" >}} Yes | Configure customizable policies that require merge request approval based on policy rules, or enforce security scanners to execute in project pipelines for compliance requirements. Policies can be enforced granularly against specific projects, or all projects in a group or subgroup. |
|
||||
|
||||
## Other compliance features
|
||||
|
||||
These features can also help with compliance requirements:
|
||||
|
||||
| Feature | Instances | Groups | Projects | Description |
|
||||
|:-------------------------------------------------------------------------------------------------------------------------------|:-------------------------------------|:-------------------------------------|:-------------------------------------|:------------|
|
||||
| [External Status Checks](../project/merge_requests/status_checks.md) | {{< icon name="dotted-circle" >}} No | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes | Interface with third-party systems you already use during development to ensure you remain compliant. |
|
||||
| [License approval policies](license_approval_policies.md) | {{< icon name="dotted-circle" >}} No | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes | Search dependencies for their licenses. This lets you determine if the licenses of your project's dependencies are compatible with your project's license. |
|
||||
| [Lock project membership to group](../group/access_and_permissions.md#prevent-members-from-being-added-to-projects-in-a-group) | {{< icon name="dotted-circle" >}} No | {{< icon name="check-circle" >}} Yes | {{< icon name="dotted-circle" >}} No | Group owners can prevent new members from being added to projects in a group. |
|
||||
|
|
|
|||
|
|
@ -18,6 +18,7 @@ title: Signed commits from the GitLab UI
|
|||
- Displaying **Verified** badge for signed GitLab UI commits [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/124218) in GitLab 16.3 [with a flag](../../../../administration/feature_flags.md) named `gitaly_gpg_signing`. Disabled by default.
|
||||
- Verifying the signatures using multiple keys specified in `rotated_signing_keys` option [introduced](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/6163) in GitLab 16.3.
|
||||
- `gitaly_gpg_signing` feature flag [enabled by default](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/6876) on GitLab Self-Managed and GitLab Dedicated in GitLab 17.0.
|
||||
- Default values for `committer_name` and `committer_email` fields [introduced](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/7620) GitLab 17.9.
|
||||
|
||||
{{< /history >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -2909,6 +2909,9 @@ msgstr ""
|
|||
msgid "AccessTokens|Access tokens"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Active"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Add a %{type}"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -2945,6 +2948,21 @@ msgstr ""
|
|||
msgid "AccessTokens|Created"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Created date"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Expiration date"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Expired"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Expires"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Expiring"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Failed to revoke token"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -2957,6 +2975,14 @@ msgstr ""
|
|||
msgid "AccessTokens|For example, the application using the token or the purpose of the token. Do not give sensitive information for the name of the token, as it will be visible to all %{resource_type} members."
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|IP: %{ips}"
|
||||
msgid_plural "AccessTokens|IPs: %{ips}"
|
||||
msgstr[0] ""
|
||||
msgstr[1] ""
|
||||
|
||||
msgid "AccessTokens|Inactive"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Incoming email token"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -2972,6 +2998,24 @@ msgstr ""
|
|||
msgid "AccessTokens|Keep this token secret. Anyone who has it can read activity and issue RSS feeds or your calendar feed as if they were you. If that happens, %{linkStart}reset this token%{linkEnd}."
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Last used date"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Last used:"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Lifetime"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Name"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Never until revoked"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|No access tokens"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Not eligible to rotate token with access level higher than the user"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -2984,21 +3028,36 @@ msgstr ""
|
|||
msgid "AccessTokens|Revoke"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Revoked"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Rotate"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Scopes"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Scopes set the permission levels granted to the token."
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Search or filter access tokens..."
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Select a role"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Select scopes"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|State"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Static object token"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Status"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|The last five distinct IP addresses from where the token was used"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -3014,9 +3073,18 @@ msgstr ""
|
|||
msgid "AccessTokens|Token description"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Token expires in less than two weeks."
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Token name"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|Usage"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|View token usage information"
|
||||
msgstr ""
|
||||
|
||||
msgid "AccessTokens|When enabled, a user will be required to enter in an expiration date when creating an access token. Changes will not affect existing token expiration dates. This setting overrides the group-level %{link_start}service account token expiration%{link_end} setting."
|
||||
msgstr ""
|
||||
|
||||
|
|
|
|||
|
|
@ -31,7 +31,6 @@ Migration/UpdateLargeTable:
|
|||
- :merge_request_diff_commits_b5377a7a34_1000000001
|
||||
- :merge_request_diff_commits_b5377a7a34_800000001
|
||||
- :merge_request_diff_files
|
||||
- :merge_request_diff_files_99208b8fac_1000000001
|
||||
- :merge_request_diffs
|
||||
- :merge_request_metrics
|
||||
- :merge_requests
|
||||
|
|
|
|||
|
|
@ -174,9 +174,6 @@ RSpec.describe 'Database schema',
|
|||
# merge_request_diff_commits_b5377a7a34 is the temporary table for the merge_request_diff_commits partitioning
|
||||
# backfill. It will get foreign keys after the partitioning is finished.
|
||||
merge_request_diff_commits_b5377a7a34: %w[merge_request_diff_id commit_author_id committer_id project_id],
|
||||
# merge_request_diff_files_99208b8fac is the temporary table for the merge_request_diff_commits partitioning
|
||||
# backfill. It will get foreign keys after the partitioning is finished.
|
||||
merge_request_diff_files_99208b8fac: %w[merge_request_diff_id project_id],
|
||||
merge_request_user_mentions: %w[project_id],
|
||||
namespaces: %w[owner_id parent_id],
|
||||
namespace_descendants: %w[namespace_id],
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@ RSpec.describe 'new tables missing sharding_key', feature_category: :cell do
|
|||
let(:allowed_to_be_missing_sharding_key) do
|
||||
[
|
||||
'merge_request_diff_commits_b5377a7a34', # has a desired sharding key instead
|
||||
'merge_request_diff_files_99208b8fac', # has a desired sharding key instead
|
||||
'p_ci_pipeline_variables', # has a desired sharding key instead
|
||||
'web_hook_logs_daily' # temporary copy of web_hook_logs
|
||||
]
|
||||
|
|
|
|||
Loading…
Reference in New Issue