diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2021-10-20 15:13:26 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2021-10-20 15:13:26 +0300 |
commit | 3ce7340b2ae954b6b449bfba5720fa356b803c51 (patch) | |
tree | ab1cc089c519d0f94993142071556aa6027f0589 /doc | |
parent | c2afac6a378d1aaaa7448892d042cdb59ee2c290 (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc')
-rw-r--r-- | doc/architecture/blueprints/consolidating_groups_and_projects/index.md | 19 | ||||
-rw-r--r-- | doc/ci/yaml/index.md | 55 | ||||
-rw-r--r-- | doc/development/database/multiple_databases.md | 56 | ||||
-rw-r--r-- | doc/user/group/index.md | 10 | ||||
-rw-r--r-- | doc/user/group/value_stream_analytics/index.md | 6 |
5 files changed, 138 insertions, 8 deletions
diff --git a/doc/architecture/blueprints/consolidating_groups_and_projects/index.md b/doc/architecture/blueprints/consolidating_groups_and_projects/index.md index a8d87e5f967..d75c2c8e703 100644 --- a/doc/architecture/blueprints/consolidating_groups_and_projects/index.md +++ b/doc/architecture/blueprints/consolidating_groups_and_projects/index.md @@ -6,7 +6,7 @@ comments: false description: Consolidating groups and projects --- -# Consolidating Group and Project +# Consolidating Groups and Projects There are numerous features that exist exclusively within groups or projects. The boundary between group and project features used to be clear. @@ -127,6 +127,22 @@ The work required to establish `Namespace` as a container for our features is tracked under [Consolidate Groups and Projects](https://gitlab.com/groups/gitlab-org/-/epics/6473) epic. +## Migrating features to Namespaces + +The initial iteration will provide a framework to house features under `Namespaces`. Stage groups will eventually need to migrate their own features and functionality over to `Namespaces`. This may impact these features in unexpected ways. Therefore, to minimize UX debt and maintain product consistency, stage groups will have to consider a number of factors when migrating their features over to `Namespaces`: + +1. **Conceptual model**: What are the current and future state conceptual models of these features ([see object modeling for designers](https://hpadkisson.medium.com/object-modeling-for-designers-an-introduction-7871bdcf8baf))? These should be documented in Pajamas (example: [Merge Requests](https://design.gitlab.com/objects/merge-request)). +1. **Merge conflicts**: What inconsistencies are there across project, group, and admin levels? How might these be addressed? For an example of how we rationalized this for labels, please see [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/338820). +1. **Inheritence & information flow**: How is information inherited across our container hierarchy currently? How might this be impacted if complying with the new [inheritence behavior](https://gitlab.com/gitlab-org/gitlab/-/issues/343316) framework? +1. **Settings**: Where can settings for this feature be found currently? How will these be impacted by `Namespaces`? +1. **Access**: Who can access this feature and is that impacted by the new container structure? Are there any role or privacy considerations? +1. **Tier**: Is there any tier functionality that is differentiated by projects and groups? +1. **Documentation**: Is the structure and content of documentation impacted by these changes at all? +1. **Solution proposal**: + - Think big: This analysis provides a great opportunity to zoom out and consider the feature UX as a whole. How could you make this feature lovable based on the new structure, inheritance, and capabilities afforded by `Namespaces`? Is there any UI which doesn't comply with Pajamas? + - Start small: What are the product changes that need to be made to assist with the migration? + - Move fast: Prioritise these solution ideas, document in issues, and create a roadmap for implementation. + ## Who Proposal: @@ -151,5 +167,6 @@ DRIs: | Product | Melissa Ushakov | | Leadership | Michelle Gill | | Engineering | Imre Farkas | +| Design | Nick Post | <!-- vale gitlab.Spelling = YES --> diff --git a/doc/ci/yaml/index.md b/doc/ci/yaml/index.md index 58efa56c46d..3c5a935ffbb 100644 --- a/doc/ci/yaml/index.md +++ b/doc/ci/yaml/index.md @@ -1085,6 +1085,61 @@ In this example: - `script` does not merge, but `script: ['rake rspec']` overwrites `script: ['echo "Hello world!"']`. You can use [YAML anchors](yaml_specific_features.md#anchors) to merge arrays. +##### Exclude a key from `extends` + +To exclude a key from the extended content, you must assign it to `null`, for example: + +```yaml +.base: + script: test + variables: + VAR1: base var 1 + +test1: + extends: .base + variables: + VAR1: test1 var 1 + VAR2: test2 var 2 + +test2: + extends: .base + variables: + VAR2: test2 var 2 + +test3: + extends: .base + variables: {} + +test4: + extends: .base + variables: null +``` + +Merged configuration: + +```yaml +test1: + script: test + variables: + VAR1: test1 var 1 + VAR2: test2 var 2 + +test2: + script: test + variables: + VAR1: base var 1 + VAR2: test2 var 2 + +test3: + script: test + variables: + VAR1: base var 1 + +test4: + script: test + variables: null +``` + #### Use `extends` and `include` together To reuse configuration from different configuration files, diff --git a/doc/development/database/multiple_databases.md b/doc/development/database/multiple_databases.md index 0ba752ba3a6..e21606bd3e7 100644 --- a/doc/development/database/multiple_databases.md +++ b/doc/development/database/multiple_databases.md @@ -272,6 +272,62 @@ logic to delete these rows if or whenever necessary in your domain. Finally, this de-normalization and new query also improves performance because it does less joins and needs less filtering. +##### Remove a redundant join + +Sometimes there are cases where a query is doing excess (or redundant) joins. + +A common example occurs where a query is joining from `A` to `C`, via some +table with both foreign keys, `B`. +When you only care about counting how +many rows there are in `C` and if there are foreign keys and `NOT NULL` constraints +on the foreign keys in `B`, then it might be enough to count those rows. +For example, in +[MR 71811](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/71811), it was +previously doing `project.runners.count`, which would produce a query like: + +```sql +select count(*) from projects +inner join ci_runner_projects on ci_runner_projects.project_id = projects.id +where ci_runner_projects.runner_id IN (1, 2, 3) +``` + +This was changed to avoid the cross-join by changing the code to +`project.runner_projects.count`. It produces the same response with the +following query: + +```sql +select count(*) from ci_runner_projects +where ci_runner_projects.runner_id IN (1, 2, 3) +``` + +Another common redundant join is joining all the way to another table, +then filtering by primary key when you could have instead filtered on a foreign +key. See an example in +[MR 71614](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/71614). The previous +code was `joins(scan: :build).where(ci_builds: { id: build_ids })`, which +generated a query like: + +```sql +select ... +inner join security_scans +inner join ci_builds on security_scans.build_id = ci_builds.id +where ci_builds.id IN (1, 2, 3) +``` + +However, as `security_scans` already has a foreign key `build_id`, the code +can be changed to `joins(:scan).where(security_scans: { build_id: build_ids })`, +which produces the same response with the following query: + +```sql +select ... +inner join security_scans +where security_scans.build_id IN (1, 2, 3) +``` + +Both of these examples of removing redundant joins remove the cross-joins, +but they have the added benefit of producing simpler and faster +queries. + ##### Use `disable_joins` for `has_one` or `has_many` `through:` relations Sometimes a join query is caused by using `has_one ... through:` or `has_many diff --git a/doc/user/group/index.md b/doc/user/group/index.md index 3b21f192f47..e3da576cd99 100644 --- a/doc/user/group/index.md +++ b/doc/user/group/index.md @@ -95,10 +95,8 @@ For details about groups, watch [GitLab Namespaces (users, groups and subgroups) You can give a user access to all projects in a group. -1. On the top bar, select **Menu > Groups**. -1. Select **Your Groups**. -1. Find your group and select it. -1. From the left sidebar, select **Group information > Members**. +1. On the top bar, select **Menu > Groups** and find your group. +1. On the left sidebar, select **Group information > Members**. 1. Fill in the fields. - The role applies to all projects in the group. [Learn more about permissions](../permissions.md). - On the **Access expiration date**, the user can no longer access projects in the group. @@ -107,9 +105,7 @@ You can give a user access to all projects in a group. As a user, you can request to be a member of a group, if an administrator allows it. -1. On the top bar, select **Menu > Groups**. -1. Select **Your Groups**. -1. Find the group and select it. +1. On the top bar, select **Menu > Groups** and find your group. 1. Under the group name, select **Request Access**. As many as ten of the most-recently-active group owners receive an email with your request. diff --git a/doc/user/group/value_stream_analytics/index.md b/doc/user/group/value_stream_analytics/index.md index 5c8393f30ab..3b0eefeb909 100644 --- a/doc/user/group/value_stream_analytics/index.md +++ b/doc/user/group/value_stream_analytics/index.md @@ -87,6 +87,12 @@ The "Time" metrics near the top of the page are measured as follows: - **Lead time**: median time from issue created to issue closed. - **Cycle time**: median time from first commit to issue closed. (You can associate a commit with an issue by [crosslinking in the commit message](../../project/issues/crosslinking_issues.md#from-commit-messages).) +- **Lead Time for Changes**: median time between when a merge request is merged and deployed to a +production environment for all merge requests deployed in the given time period. +[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/340150) in GitLab 14.5 (**Ultimate** +tier only). + +- **Lead Time for Changes**: median duration between merge request merge and deployment to a production environment for all MRs deployed in the given time period. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/340150) in GitLab 14.5 (**Ultimate** tier only). The "Recent Activity" metrics near the top of the page are measured as follows: |