diff options
Diffstat (limited to 'doc')
-rw-r--r-- | doc/api/repositories.md | 11 | ||||
-rw-r--r-- | doc/ci/variables/README.md | 4 | ||||
-rw-r--r-- | doc/ci/yaml/README.md | 18 | ||||
-rw-r--r-- | doc/development/deleting_migrations.md | 2 | ||||
-rw-r--r-- | doc/development/feature_flags/development.md | 20 | ||||
-rw-r--r-- | doc/user/compliance/compliance_dashboard/img/compliance_dashboard_v13_3.png | bin | 41721 -> 0 bytes | |||
-rw-r--r-- | doc/user/project/merge_requests/merge_request_approvals.md | 34 |
7 files changed, 41 insertions, 48 deletions
diff --git a/doc/api/repositories.md b/doc/api/repositories.md index 79ccd5bc9e4..305216f853a 100644 --- a/doc/api/repositories.md +++ b/doc/api/repositories.md @@ -199,6 +199,9 @@ authentication if the repository is publicly accessible. GET /projects/:id/repository/contributors ``` +CAUTION: **Deprecation:** +The `additions` and `deletions` attributes are deprecated [as of GitLab 13.4](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/39653) because they [always return `0`](https://gitlab.com/gitlab-org/gitlab/-/issues/233119). + Parameters: - `id` (required) - The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user @@ -212,14 +215,14 @@ Response: "name": "Example User", "email": "example@example.com", "commits": 117, - "additions": 2097, - "deletions": 517 + "additions": 0, + "deletions": 0 }, { "name": "Sample User", "email": "sample@example.com", "commits": 33, - "additions": 338, - "deletions": 244 + "additions": 0, + "deletions": 0 }] ``` diff --git a/doc/ci/variables/README.md b/doc/ci/variables/README.md index 8f137b6436a..61bc466692e 100644 --- a/doc/ci/variables/README.md +++ b/doc/ci/variables/README.md @@ -760,9 +760,9 @@ Examples: - `($VARIABLE1 =~ /^content.*/ || $VARIABLE2 =~ /thing$/) && $VARIABLE3` - `$CI_COMMIT_BRANCH == "my-branch" || (($VARIABLE1 == "thing" || $VARIABLE2 == "thing") && $VARIABLE3)` -The feature is currently deployed behind a feature flag that is **disabled by default**. +The feature is currently deployed behind a feature flag that is **enabled by default**. [GitLab administrators with access to the GitLab Rails console](../../administration/feature_flags.md) -can opt to enable it for your instance. +can opt to disable it for your instance. To enable it: diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index e6e84fbc3cb..82a410129a6 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -1989,9 +1989,7 @@ This example creates four paths of execution: - The maximum number of jobs that a single job can need in the `needs:` array is limited: - For GitLab.com, the limit is ten. For more information, see our [infrastructure issue](https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/7541). - - For self-managed instances, the limit is: - - 10, if the `ci_plan_needs_size_limit` feature flag is disabled (default). - - 50, if the `ci_plan_needs_size_limit` feature flag is enabled. This limit [can be changed](#changing-the-needs-job-limit-core-only). + - For self-managed instances, the limit is: 50. This limit [can be changed](#changing-the-needs-job-limit-core-only). - If `needs:` refers to a job that is marked as `parallel:`. the current job will depend on all parallel jobs created. - `needs:` is similar to `dependencies:` in that it needs to use jobs from prior stages, @@ -2002,18 +2000,10 @@ This example creates four paths of execution: ##### Changing the `needs:` job limit **(CORE ONLY)** -The maximum number of jobs that can be defined within `needs:` defaults to 10. +The maximum number of jobs that can be defined within `needs:` defaults to 50. -To change this limit to 50 on a self-managed installation, a GitLab administrator -with [access to the GitLab Rails console](../../administration/feature_flags.md) -can enable the `:ci_plan_needs_size_limit` feature flag: - -```ruby -Feature::enable(:ci_plan_needs_size_limit) -``` - -After the feature flag is enabled, you can choose a custom limit. For example, to -set the limit to 100: +A GitLab administrator with [access to the GitLab Rails console](../../administration/feature_flags.md) +can choose a custom limit. For example, to set the limit to 100: ```ruby Plan.default.actual_limits.update!(ci_needs_size_limit: 100) diff --git a/doc/development/deleting_migrations.md b/doc/development/deleting_migrations.md index 8aa16710d55..b8f23019ac2 100644 --- a/doc/development/deleting_migrations.md +++ b/doc/development/deleting_migrations.md @@ -23,7 +23,7 @@ Migrations can be disabled if: In order to disable a migration, the following steps apply to all types of migrations: 1. Turn the migration into a no-op by removing the code inside `#up`, `#down` - or `#perform` methods, and adding `#no-op` comment instead. + or `#perform` methods, and adding `# no-op` comment instead. 1. Add a comment explaining why the code is gone. Disabling migrations requires explicit approval of Database Maintainer. diff --git a/doc/development/feature_flags/development.md b/doc/development/feature_flags/development.md index cb97a775409..9b30187fcd1 100644 --- a/doc/development/feature_flags/development.md +++ b/doc/development/feature_flags/development.md @@ -78,19 +78,21 @@ Only feature flags that have a YAML definition file can be used when running the ```shell $ bin/feature-flag my-feature-flag >> Please specify the group introducing feature flag, like `group::apm`: - ?> group::memory ->> Open this URL and fill the rest of details: -https://gitlab.com/gitlab-org/gitlab/-/issues/new?issue[title]=%5BFeature+flag%5D+Rollout+of+%60my-feature-flag%60& ->> Paste URL here, or enter to skip: +>> If you have MR open, can you paste the URL here? (or enter to skip) +?> https://gitlab.com/gitlab-org/gitlab/-/merge_requests/38602 + +>> Open this URL and fill the rest of details: +https://gitlab.com/gitlab-org/gitlab/-/issues/new?issue%5Btitle%5D=%5BFeature+flag%5D+Rollout+of+%60test-flag%60&issuable_template=Feature+Flag+Roll+Out -?> -create config/feature_flags/development/my_feature_flag.yml +>> Paste URL of `rollout issue` here, or enter to skip: +?> https://gitlab.com/gitlab-org/gitlab/-/issues/232533 +create config/feature_flags/development/test-flag.yml --- -name: my_feature_flag -introduced_by_url: -rollout_issue_url: +name: test-flag +introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/38602 +rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/232533 group: group::memory type: development default_enabled: false diff --git a/doc/user/compliance/compliance_dashboard/img/compliance_dashboard_v13_3.png b/doc/user/compliance/compliance_dashboard/img/compliance_dashboard_v13_3.png Binary files differdeleted file mode 100644 index bf759f44dc5..00000000000 --- a/doc/user/compliance/compliance_dashboard/img/compliance_dashboard_v13_3.png +++ /dev/null diff --git a/doc/user/project/merge_requests/merge_request_approvals.md b/doc/user/project/merge_requests/merge_request_approvals.md index b8a4d513318..407fc5db425 100644 --- a/doc/user/project/merge_requests/merge_request_approvals.md +++ b/doc/user/project/merge_requests/merge_request_approvals.md @@ -1,7 +1,7 @@ --- stage: Create group: Source Code -info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers +info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers" type: reference, concepts --- @@ -13,16 +13,16 @@ process, as it clearly communicates the ability to merge the change. ## Optional Approvals **(CORE ONLY)** -> Introduced in [GitLab Core 13.2](https://gitlab.com/gitlab-org/gitlab/-/issues/27426). +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/27426) in GitLab 13.2. -Any user with Developer or greater [permissions](../../permissions.md) can approve a merge request in GitLab Core. -This provides a consistent mechanism for reviewers to provide approval, and makes it easy for +Any user with Developer or greater [permissions](../../permissions.md) can approve a merge request in GitLab Core and higher tiers. +This provides a consistent mechanism for reviewers to approve merge requests, and makes it easy for maintainers to know when a change is ready to merge. Approvals in Core are optional and do not prevent a merge request from being merged when there is no approval. ## Required Approvals **(STARTER)** -> Introduced in [GitLab Enterprise Edition 7.12](https://about.gitlab.com/releases/2015/06/22/gitlab-7-12-released/#merge-request-approvers-ee-only). +> [Introduced](https://about.gitlab.com/releases/2015/06/22/gitlab-7-12-released/#merge-request-approvers-ee-only) in GitLab Enterprise Edition 7.12. Available in [GitLab Starter](https://about.gitlab.com/pricing/) and higher tiers. Required approvals enable enforced code review by requiring specified people to approve a merge request before it can be merged. @@ -33,8 +33,8 @@ Required approvals enable multiple use cases: - Specifying reviewers for a given proposed code change, as well as a minimum number of reviewers, through [Approval rules](#approval-rules). - Specifying categories of reviewers, such as backend, frontend, quality assurance, - database, etc., for all proposed code changes. -- Automatically designating [Code Owners as eligible approvers](#code-owners-as-eligible-approvers), + database, and so on, for all proposed code changes. +- Designating [Code Owners as eligible approvers](#code-owners-as-eligible-approvers), determined by the files changed in a merge request. - [Requiring approval from a security team](#security-approvals-in-merge-requests-ultimate) before merging code that could introduce a vulnerability.**(ULTIMATE)** @@ -50,14 +50,10 @@ be merged, and optionally which users should do the approving. Approvals can be If no approval rules are defined, any user can approve a merge request, though the default minimum number of required approvers can still be set in the [project settings for merge request approvals](#merge-request-approvals-project-settings). -Approval rules define how many approvals a merge request must receive before it can -be merged, and optionally which users should do the approving. Approvals can be defined: - -- [As project defaults](#adding--editing-a-default-approval-rule). -- [Per merge request](#editing--overriding-approval-rules-per-merge-request). - -If no approval rules are defined, any user can approve a merge request, though the default -minimum number of required approvers can still be set in the [project settings for merge request approvals](#merge-request-approvals-project-settings). +You can opt to define one single rule to approve a merge request among the available rules +or choose more than one. Single approval rules are available in GitLab Starter and higher tiers, +while [multiple approval rules](#multiple-approval-rules-premium) are available in +[GitLab Premium](https://about.gitlab.com/pricing/) and above. NOTE: **Note:** On GitLab.com, you can add a group as an approver if you're a member of that group or the @@ -88,6 +84,11 @@ if [**Prevent author approval**](#allowing-merge-request-authors-to-approve-thei and [**Prevent committers approval**](#prevent-approval-of-merge-requests-by-their-committers) (disabled by default) are enabled on the project settings. +[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10294) in [GitLab Starter](https://about.gitlab.com/pricing/) 13.3, +when an eligible approver comments on a merge request, it appears in the **Commented by** column of the Approvals widget, +indicating who has engaged in the merge request review. Authors and reviewers can also easily identify who they should reach out +to if they have any questions or inputs about the content of the merge request. + ##### Implicit Approvers If the number of required approvals is greater than the number of assigned approvers, @@ -187,9 +188,6 @@ a rule is already defined. When an [eligible approver](#eligible-approvers) approves a merge request, it will reduce the number of approvals left for all rules that the approver belongs to. -When an [eligible approver](#eligible-approvers) comments on a merge request, it -appears in the **Commented by** column. This feature was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10294) in GitLab 13.3. - ![Approvals premium merge request widget](img/approvals_premium_mr_widget_v13_3.png) #### Scoped to Protected Branch **(PREMIUM)** |