diff options
Diffstat (limited to 'doc/development/merge_request_concepts')
5 files changed, 13 insertions, 39 deletions
diff --git a/doc/development/merge_request_concepts/approval_rules.md b/doc/development/merge_request_concepts/approval_rules.md index d119644cd7c..d6000d48706 100644 --- a/doc/development/merge_request_concepts/approval_rules.md +++ b/doc/development/merge_request_concepts/approval_rules.md @@ -4,7 +4,7 @@ group: Code Review info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Approval Rules development guide +# Approval rules development guidelines This document explains the backend design and flow of all related functionality about [merge request approval rules](../../user/project/merge_requests/approvals/index.md). diff --git a/doc/development/merge_request_concepts/diffs/frontend.md b/doc/development/merge_request_concepts/diffs/frontend.md index 6bd6d80af94..ff163050e1f 100644 --- a/doc/development/merge_request_concepts/diffs/frontend.md +++ b/doc/development/merge_request_concepts/diffs/frontend.md @@ -84,40 +84,9 @@ The most important part of the metadata response is the diff file names. This da app to render the file browser inside of the diffs app, without waiting for all batch diffs requests to complete. -When the metadata response is received, the diff file data gets sent to a web worker. The web worker -exists to allow for this data, which for larger merge requests could be huge, to be processed off -the main thread. Processing this data involves getting the data into the correct structure +When the metadata response is received, the diff file data is processed into the correct structure that the frontend requires to render the file browser in either tree view or list view. -```mermaid -graph TD - A[fetchDiffFilesMeta] - B[Create web worker] - C[Fetch data] - D[SET_DIFF_METADATA] - E[Post worker data] - F[Worker message event listener] - K[SET_TREE_DATA] - - G[TreeWorker] - H[onMessage] - I[generateTreeList] - J[postMessage sortTree] - - A -->B - E -->F - B -->C - C -->D - D -->E - - G -->H - H -->I - I -->J - J -->F - - F -->K -``` - The structure for this file object is: ```javascript @@ -128,6 +97,11 @@ The structure for this file object is: "type": "", "tree": [], "changed": true, + "diffLoaded": false, + "filePaths": { + "old": file.old_path, + "new": file.new_path + }, "tempFile": false, "deleted": false, "fileHash": "", diff --git a/doc/development/merge_request_concepts/diffs/index.md b/doc/development/merge_request_concepts/diffs/index.md index 8ef3f01aba9..c2dec5c4753 100644 --- a/doc/development/merge_request_concepts/diffs/index.md +++ b/doc/development/merge_request_concepts/diffs/index.md @@ -17,7 +17,7 @@ We rely on different sources to present diffs. These include: <!-- vale gitlab.Spelling = NO --> In January 2019, Oswaldo Ferreira hosted a Deep Dive (GitLab team members only: -`https://gitlab.com/gitlab-org/create-stage/issues/1`) on GitLab Diffs and Commenting on Diffs +`https://gitlab.com/gitlab-org/create-stage/-/issues/1`) on GitLab Diffs and Commenting on Diffs functionality to share domain-specific knowledge with anyone who may work in this part of the codebase in the future: diff --git a/doc/development/merge_request_concepts/index.md b/doc/development/merge_request_concepts/index.md index 14d9582ad84..8bec5e0c0b0 100644 --- a/doc/development/merge_request_concepts/index.md +++ b/doc/development/merge_request_concepts/index.md @@ -34,7 +34,7 @@ This area of the merge request is where all of the options and commit messages a Reports are widgets within the merge request that report information about changes within the merge request. These widgets provide information to better help the author understand the changes and further improvements to the proposed changes. -[Design Documentation](https://design.gitlab.com/regions/merge-request-reports/) +[Design Documentation](https://design.gitlab.com/patterns/merge-request-reports)  @@ -61,7 +61,7 @@ Additionally, approval settings provide configuration options to define how thos Examples of approval rules and settings include: - [Merge request approval rules](../../user/project/merge_requests/approvals/rules.md) -- [Code owner approvals](../../user/project/code_owners.md) +- [Code owner approvals](../../user/project/codeowners/index.md) - [Security approvals](../../user/application_security/index.md#security-approvals-in-merge-requests) - [Prevent editing approval rules](../../user/project/merge_requests/approvals/settings.md#prevent-editing-approval-rules-in-merge-requests) - [Remove all approvals when commits are added](../../user/project/merge_requests/approvals/settings.md#remove-all-approvals-when-commits-are-added-to-the-source-branch) diff --git a/doc/development/merge_request_concepts/performance.md b/doc/development/merge_request_concepts/performance.md index 740b8f1607b..665b84b2c40 100644 --- a/doc/development/merge_request_concepts/performance.md +++ b/doc/development/merge_request_concepts/performance.md @@ -158,7 +158,7 @@ query. This in turn makes it much harder for this code to overload a database. ## Use read replicas when possible -In a DB cluster we have many read replicas and one primary. A classic use of scaling the DB is to have read-only actions be performed by the replicas. We use [load balancing](../../administration/postgresql/database_load_balancing.md) to distribute this load. This allows for the replicas to grow as the pressure on the DB grows. +In a DB cluster we have many read replicas and one primary. A classic use of scaling the DB is to have read-only actions be performed by the replicas. We use [load balancing](../database/load_balancing.md) to distribute this load. This allows for the replicas to grow as the pressure on the DB grows. By default, queries use read-only replicas, but due to [primary sticking](../../administration/postgresql/database_load_balancing.md#primary-sticking), GitLab uses the @@ -211,7 +211,7 @@ By default, this `Gitlab::SQL::CTE` class forces materialization through adding (this behavior is implemented using a custom Arel node `Gitlab::Database::AsWithMaterialized` under the surface). WARNING: -Upgrading to GitLab 14.0 requires PostgreSQL 12 or higher. +Upgrading to GitLab 14.0 requires PostgreSQL 12 or later. ## Cached Queries @@ -260,7 +260,7 @@ It re-instantiates project object for each build, instead of using the same in-m In this particular case the workaround is fairly easy: ```ruby -ActiveRecord::Associations::Preloader.new.preload(pipeline, [builds: :project]) +ActiveRecord::Associations::Preloader.new(records: pipeline, associations: [builds: :project]).call pipeline.builds.each do |build| build.to_json(only: [:name], include: [project: { only: [:name]}]) |