diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2021-07-02 18:07:36 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2021-07-02 18:07:36 +0300 |
commit | e61f798b74e8e18fca7239fd01802182479bfcfc (patch) | |
tree | 4a49b062d8df2ffe3e6e8a07d2aadc034acb9092 /doc | |
parent | afbfbfc87abfa006f1d369fdf9c740eb1c826808 (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc')
-rw-r--r-- | doc/api/index.md | 62 | ||||
-rw-r--r-- | doc/development/changelog.md | 1 | ||||
-rw-r--r-- | doc/development/documentation/structure.md | 214 | ||||
-rw-r--r-- | doc/development/feature_flags/index.md | 4 | ||||
-rw-r--r-- | doc/development/index.md | 7 | ||||
-rw-r--r-- | doc/development/multi_version_compatibility.md | 11 | ||||
-rw-r--r-- | doc/development/sql.md | 12 | ||||
-rw-r--r-- | doc/user/admin_area/analytics/dev_ops_report.md | 13 | ||||
-rw-r--r-- | doc/user/admin_area/settings/gitaly_timeouts.md | 19 | ||||
-rw-r--r-- | doc/user/group/devops_adoption/index.md | 11 | ||||
-rw-r--r-- | doc/user/markdown.md | 3 |
11 files changed, 219 insertions, 138 deletions
diff --git a/doc/api/index.md b/doc/api/index.md index e4b7cc56aab..76d31c35b96 100644 --- a/doc/api/index.md +++ b/doc/api/index.md @@ -245,6 +245,68 @@ your [runners](../ci/runners/README.md) to be secure. Avoid: If you have an insecure GitLab Runner configuration, you increase the risk that someone tries to steal tokens from other jobs. +#### GitLab CI/CD job token scope + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/328553) in GitLab 14.1. + +- [Deployed behind a feature flag](../user/feature_flags.md), disabled by default. +- Disabled on GitLab.com. +- Not recommended for production use. +- To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-ci-job-token-scope). **(FREE SELF)** + +This in-development feature might not be available for your use. There can be +[risks when enabling features still in development](../user/feature_flags.md#risks-when-enabling-features-still-in-development). +Refer to this feature's version history for more details. + +CI job token can access only projects that are defined in its scope. +You can configure the scope via project settings. + +The CI job token scope consists in a allowlist of projects that are authorized by maintainers to be +accessible via a CI job token. By default a scope only contains the same project where the token +comes from. Other projects can be added and removed by maintainers. + +You can configure the scope via project settings. + +Since GitLab 14.1 this setting is enabled by default for new projects. Existing projects are +recommended to enable this feature and configure which projects are authorized to be accessed +by a job token. + +The CI job token scope limits the risks that a leaked token is used to access private data that +the user associated to the job can access to. + +When the job token scope feature is enabled in the project settings, only the projects in scope +will be allowed to be accessed by a job token. If the job token scope feature is disabled, any +projects can be accessed, as long as the user associated to the job has permissions. + +For example. If a project `A` has a running job with a `CI_JOB_TOKEN`, its scope is defined by +project `A`. If the job wants to use the `CI_JOB_TOKEN` to access data from project `B` or +trigger some actions in that project, then project `B` must be in the job token scope for `A`. + +A job token might give extra permissions that aren't necessary to access specific resources. +There is [a proposal](https://gitlab.com/groups/gitlab-org/-/epics/3559) to redesign the feature +for more strategic control of the access permissions. + +<!-- Add this at the end of the file --> + +#### Enable or disable CI Job Token Scope **(FREE SELF)** + +This is under development and not ready for production use. It is +deployed behind a feature flag that is **disabled by default**. +[GitLab administrators with access to the GitLab Rails console](../administration/feature_flags.md) +can enable it. + +To enable it: + +```ruby +Feature.enable(:ci_scoped_job_token) +``` + +To disable it: + +```ruby +Feature.disable(:ci_scoped_job_token) +``` + ### Impersonation tokens Impersonation tokens are a type of [personal access token](../user/profile/personal_access_tokens.md). diff --git a/doc/development/changelog.md b/doc/development/changelog.md index c9d2d820c54..c96fe2c18c1 100644 --- a/doc/development/changelog.md +++ b/doc/development/changelog.md @@ -98,6 +98,7 @@ EE: true database records created during Cycle Analytics model spec." - _Any_ contribution from a community member, no matter how small, **may** have a changelog entry regardless of these guidelines if the contributor wants one. +- [Removing](feature_flags/#changelog) a feature flag, when the new code is retained. ## Writing good changelog entries diff --git a/doc/development/documentation/structure.md b/doc/development/documentation/structure.md index 9449fd52839..4fe3458b909 100644 --- a/doc/development/documentation/structure.md +++ b/doc/development/documentation/structure.md @@ -7,37 +7,40 @@ description: What to include in GitLab documentation pages. # Documentation topic types -At GitLab, we have not traditionally used topic types. However, we are starting to -move in this direction, and we now use four topic types: +At GitLab, we have not traditionally used types for our content. However, we are starting to +move in this direction, and we now use four primary topic types: - [Concept](#concept) - [Task](#task) - [Reference](#reference) - [Troubleshooting](#troubleshooting) -Each page contains multiple topic types. For example, -a page with the title `Pipelines`, which is generated from a file called `index.md`, -can include a concept and multiple task and reference topics. +In general, each page in our docset contains multiple topics. (Each heading indicates a new topic.) +Each topic on a page should be a specific topic type. For example, +a page with the title `Pipelines` can include topics that are concepts and tasks. + +A page might also contain only one type of information. These pages are generally one of our +[other content types](#other-types-of-content). ## Concept -A concept topic introduces a single feature or concept. +A concept introduces a single feature or concept. A concept should answer the questions: - What is this? - Why would I use it? -Think of everything someone might want to know if they've never heard of this topic before. +Think of everything someone might want to know if they've never heard of this concept before. Don't tell them **how** to do this thing. Tell them **what it is**. -If you start describing another topic, start a new concept and link to it. +If you start describing another concept, start a new concept and link to it. -Also, do not use "Overview" or "Introduction" for the topic title. Instead, +Also, do not use **Overview** or **Introduction** for the title. Instead, use a noun or phrase that someone would search for. -Concept topics should be in this format: +Concepts should be in this format: ```markdown # Title (a noun, like "Widgets") @@ -47,14 +50,14 @@ A paragraph that explains what this thing is. Another paragraph that explains what this thing is. Remember, if you start to describe about another concept, stop yourself. -Each concept topic should be about one concept only. +Each concept should be about one concept only. ``` ## Task -A task topic gives instructions for how to complete a procedure. +A task gives instructions for how to complete a procedure. -Task topics should be in this format: +Tasks should be in this format: ```markdown # Title (starts with an active verb, like "Create a widget" or "Delete a widget") @@ -89,20 +92,21 @@ Prerequisites: To create an issue: -1. Go to **Issues > List**. -1. In the top right, select **New issue**. -1. Complete the fields. (If you have a reference topic that lists each field, link to it here.) +1. On the top bar, select **Menu > Projects** and find your project. +1. On the left sidebar, select **Issues > List**. +1. In the top right corner, select **New issue**. +1. Complete the fields. (If you have reference content that lists each field, link to it here.) 1. Select **Create issue**. The issue is created. You can view it by going to **Issues > List**. ``` -If you have several tasks on a page that share prerequisites, you can make a -reference topic with the title **Prerequisites**, and link to it. +If you have several tasks on a page that share prerequisites, you can use the title +**Prerequisites**, and link to it. ## Reference -A reference topic provides information in an easily-scannable format, +Reference information should be in an easily-scannable format, like a table or list. It's similar to a dictionary or encyclopedia entry. ```markdown @@ -115,18 +119,18 @@ Introductory sentence. | **Name** | Descriptive sentence about the setting. | ``` -If a feature or concept has its own prerequisites, you can use the reference -topic type to create a **Prerequisites** header for the information. +If a feature or concept has its own prerequisites, you can use reference +content to create a **Prerequisites** header for the information. ## Troubleshooting -Troubleshooting topics can be one of two categories: +Troubleshooting can be one of two categories: -- **Troubleshooting task.** This topic is written the same as a [standard task topic](#task). +- **Troubleshooting task.** This information is written the same way as a [standard task](#task). For example, "Run debug tools" or "Verify syntax." -- **Troubleshooting reference.** This topic has a specific format. +- **Troubleshooting reference.** This information has a specific format. -Troubleshooting reference topics should be in this format: +Troubleshooting reference information should be in this format: ```markdown # Title (the error message or a description of it) @@ -138,104 +142,24 @@ This issue occurs when... The workaround is... ``` -For the topic title: +For the heading: -- Consider including at least a partial error message in the title. +- Consider including at least a partial error message. - Use fewer than 70 characters. -Remember to include the complete error message in the topics content if it is -not complete in the title. - -## Other information on a topic - -Topics include other information. - -For example: - -- Each topic must have a [tier badge](styleguide/index.md#product-tier-badges). -- New topics must have information about the - [GitLab version where the feature was introduced](styleguide/index.md#where-to-put-version-text). - -### Help and feedback section - -This section ([introduced](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests/319) in GitLab 11.4) -is displayed at the end of each document and can be omitted by adding a key into -the front matter: - -```yaml ---- -feedback: false ---- -``` - -The default is to leave it there. If you want to omit it from a document, you -must check with a technical writer before doing so. - -#### Disqus - -We also have integrated the docs site with Disqus (introduced by -[!151](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests/151)), -allowing our users to post comments. - -To omit only the comments from the feedback section, use the following key in -the front matter: - -```yaml ---- -comments: false ---- -``` - -We're hiding comments only in main index pages, such as [the main documentation index](../../index.md), -since its content is too broad to comment on. Before omitting Disqus, you must -check with a technical writer. - -Note that after adding `feedback: false` to the front matter, it will omit -Disqus, therefore, don't add both keys to the same document. - -The click events in the feedback section are tracked with Google Tag Manager. -The conversions can be viewed on Google Analytics by navigating to -**Behavior > Events > Top events > docs**. - -### Guidelines for good practices - -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36576/) in GitLab 13.2 as GitLab Development documentation. - -*Good practice* examples demonstrate encouraged ways of writing code while -comparing with examples of practices to avoid. These examples are labeled as -*Bad* or *Good*. In GitLab development guidelines, when presenting the cases, -it's recommended to follow a *first-bad-then-good* strategy. First demonstrate -the *Bad* practice (how things *could* be done, which is often still working -code), and then how things *should* be done better, using a *Good* example. This -is typically an improved example of the same code. - -Consider the following guidelines when offering examples: - -- First, offer the *Bad* example, and then the *Good* one. -- When only one bad case and one good case is given, use the same code block. -- When more than one bad case or one good case is offered, use separated code - blocks for each. With many examples being presented, a clear separation helps - the reader to go directly to the good part. Consider offering an explanation - (for example, a comment, or a link to a resource) on why something is bad - practice. -- Better and best cases can be considered part of the good case(s) code block. - In the same code block, precede each with comments: `# Better` and `# Best`. - -Although the bad-then-good approach is acceptable for the GitLab development -guidelines, do not use it for user documentation. For user documentation, use -*Do* and *Don't*. For examples, see the [Pajamas Design System](https://design.gitlab.com/content/punctuation/). +If you do not put the full error in the title, include it in the body text. ## Other types of content There are other types of content in the GitLab documentation that don't -classify as one of the four [topic types](#documentation-topic-types). +classify as one of the four primary [topic types](#documentation-topic-types). These include: - [Tutorials](#tutorials) - [Get started pages](#get-started) - [Topics and resources pages](#topics-and-resources-pages) -In most cases, these content types are on their own standalone page. +In most cases, these pages are standalone. ### Tutorials @@ -315,10 +239,78 @@ or you have to create one, use this format: Brief sentence to describe the feature. -The following topics and resources can help you understand and work with this feature: +Refer to these resources for more information about <this feature>: - Link 1 - Link 2 - Link 3 +``` + +## Help and feedback section + +This section ([introduced](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests/319) in GitLab 11.4) +is displayed at the end of each document and can be omitted by adding a key into +the front matter: + +```yaml +--- +feedback: false +--- +``` + +The default is to leave it there. If you want to omit it from a document, you +must check with a technical writer before doing so. + +### Disqus + +We also have integrated the docs site with Disqus (introduced by +[!151](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests/151)), +allowing our users to post comments. + +To omit only the comments from the feedback section, use the following key in +the front matter: +```yaml +--- +comments: false +--- ``` + +We're hiding comments only in main index pages, such as [the main documentation index](../../index.md), +since its content is too broad to comment on. Before omitting Disqus, you must +check with a technical writer. + +Note that after adding `feedback: false` to the front matter, it will omit +Disqus, therefore, don't add both keys to the same document. + +The click events in the feedback section are tracked with Google Tag Manager. +The conversions can be viewed on Google Analytics by navigating to +**Behavior > Events > Top events > docs**. + +## Guidelines for good practices + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36576/) in GitLab 13.2 as GitLab Development documentation. + +*Good practice* examples demonstrate encouraged ways of writing code while +comparing with examples of practices to avoid. These examples are labeled as +*Bad* or *Good*. In GitLab development guidelines, when presenting the cases, +it's recommended to follow a *first-bad-then-good* strategy. First demonstrate +the *Bad* practice (how things *could* be done, which is often still working +code), and then how things *should* be done better, using a *Good* example. This +is typically an improved example of the same code. + +Consider the following guidelines when offering examples: + +- First, offer the *Bad* example, and then the *Good* one. +- When only one bad case and one good case is given, use the same code block. +- When more than one bad case or one good case is offered, use separated code + blocks for each. With many examples being presented, a clear separation helps + the reader to go directly to the good part. Consider offering an explanation + (for example, a comment, or a link to a resource) on why something is bad + practice. +- Better and best cases can be considered part of the good case(s) code block. + In the same code block, precede each with comments: `# Better` and `# Best`. + +Although the bad-then-good approach is acceptable for the GitLab development +guidelines, do not use it for user documentation. For user documentation, use +*Do* and *Don't*. For examples, see the [Pajamas Design System](https://design.gitlab.com/content/punctuation/). diff --git a/doc/development/feature_flags/index.md b/doc/development/feature_flags/index.md index ac5a7268c54..397153a0abb 100644 --- a/doc/development/feature_flags/index.md +++ b/doc/development/feature_flags/index.md @@ -21,6 +21,10 @@ All newly-introduced feature flags should be [disabled by default](https://about NOTE: This document is the subject of continued work as part of an epic to [improve internal usage of Feature Flags](https://gitlab.com/groups/gitlab-org/-/epics/3551). Raise any suggestions as new issues and attach them to the epic. +## When to use feature flags + +Moved to the ["When to use feature flags"](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags) section in the handbook. + ## Feature flags in GitLab development The following highlights should be considered when deciding if feature flags diff --git a/doc/development/index.md b/doc/development/index.md index bc996fdff21..e26dd6e105c 100644 --- a/doc/development/index.md +++ b/doc/development/index.md @@ -143,6 +143,13 @@ In these cases, use the following workflow: for final content review and merge. The Technical Writer may ask for additional approvals as previously suggested before merging the MR. +### Reviewer values + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/57293) in GitLab 14.1. + +As a reviewer or as a reviewee, make sure to familiarize yourself with +the [reviewer values](https://about.gitlab.com/handbook/engineering/workflow/reviewer-values/) we strive for at GitLab. + ## UX and Frontend guides - [GitLab Design System](https://design.gitlab.com/), for building GitLab with diff --git a/doc/development/multi_version_compatibility.md b/doc/development/multi_version_compatibility.md index acdf8194cb1..8e49afda579 100644 --- a/doc/development/multi_version_compatibility.md +++ b/doc/development/multi_version_compatibility.md @@ -43,6 +43,10 @@ Is it ok if all GitLab nodes have been updated, but the post-deployment migratio Is it ok if all nodes have been updated, and then the post-deployment migrations get executed a couple days later, and then the background migrations take a week to finish? +### When upgrading a dependency like Rails + +Is it ok that some nodes have the new Rails version, but some nodes have the old Rails version? + ## A walkthrough of an update Backwards compatibility problems during updates are often very subtle. This is why it is worth familiarizing yourself with [update instructions](../update/index.md), [reference architectures](../administration/reference_architectures/index.md), and [GitLab.com's architecture](https://about.gitlab.com/handbook/engineering/infrastructure/production/architecture/). But to illustrate how these problems arise, take a look at this example of a simple update. @@ -102,6 +106,13 @@ Yes! We have specific instructions for [zero-downtime updates](../update/index.m ## I've identified a potential backwards compatibility problem, what can I do about it? +### Coordinate + +For major or minor version updates of Rails or Puma: + +- Engage the Quality team to thoroughly test the MR. +- Notify the `@gitlab-org/release/managers` on the MR prior to merging. + ### Feature flags One way to handle this is to use a feature flag that is disabled by diff --git a/doc/development/sql.md b/doc/development/sql.md index a98645cfcae..ddca88cb9bb 100644 --- a/doc/development/sql.md +++ b/doc/development/sql.md @@ -70,7 +70,7 @@ WHERE title ILIKE '%Draft:%'; Because the value for `ILIKE` starts with a wildcard the database is not able to use an index as it doesn't know where to start scanning the indexes. -Luckily, PostgreSQL _does_ provide a solution: trigram GIN indexes. These +Luckily, PostgreSQL _does_ provide a solution: trigram Generalized Inverted Index (GIN) indexes. These indexes can be created as follows: ```sql @@ -261,9 +261,9 @@ from `ActiveRecord::Base`. ## Use UNIONs -UNIONs aren't very commonly used in most Rails applications but they're very -powerful and useful. In most applications queries tend to use a lot of JOINs to -get related data or data based on certain criteria, but JOIN performance can +`UNION`s aren't very commonly used in most Rails applications but they're very +powerful and useful. Queries tend to use a lot of `JOIN`s to +get related data or data based on certain criteria, but `JOIN` performance can quickly deteriorate as the data involved grows. For example, if you want to get a list of projects where the name contains a @@ -279,7 +279,7 @@ OR namespaces.name ILIKE '%gitlab%'; ``` Using a large database this query can easily take around 800 milliseconds to -run. Using a UNION we'd write the following instead: +run. Using a `UNION` we'd write the following instead: ```sql SELECT projects.* @@ -301,7 +301,7 @@ This doesn't mean you should start using UNIONs everywhere, but it's something to keep in mind when using lots of JOINs in a query and filtering out records based on the joined data. -GitLab comes with a `Gitlab::SQL::Union` class that can be used to build a UNION +GitLab comes with a `Gitlab::SQL::Union` class that can be used to build a `UNION` of multiple `ActiveRecord::Relation` objects. You can use this class as follows: diff --git a/doc/user/admin_area/analytics/dev_ops_report.md b/doc/user/admin_area/analytics/dev_ops_report.md index cb94bc8d35b..3c5c646f86c 100644 --- a/doc/user/admin_area/analytics/dev_ops_report.md +++ b/doc/user/admin_area/analytics/dev_ops_report.md @@ -39,25 +39,28 @@ collected before this feature is available. ## DevOps Adoption **(ULTIMATE SELF)** > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/247112) in GitLab 13.7 as a [Beta feature](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta). -> - The Overview tab [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/330401) in GitLab 14.1. > - [Deployed behind a feature flag](../../../user/feature_flags.md), disabled by default. > - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/59267) in GitLab 14.0. > - Enabled on GitLab.com. > - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#disable-or-enable-devops-adoption). **(ULTIMATE SELF)** +> - The Overview tab [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/330401) in GitLab 14.1. +> - DAST and SAST metrics [added](https://gitlab.com/gitlab-org/gitlab/-/issues/328033) in GitLab 14.1. DevOps Adoption shows you which groups within your organization are using the most essential features of GitLab: - Dev - - Issues - - Merge Requests - Approvals - Code owners + - Issues + - Merge requests - Sec + - DAST + - SAST - Scans - Ops - - Runners - - Pipelines - Deployments + - Pipelines + - Runners When managing groups in the UI, you can add your groups with the **Add group to table** button, in the top right hand section the page. diff --git a/doc/user/admin_area/settings/gitaly_timeouts.md b/doc/user/admin_area/settings/gitaly_timeouts.md index 6f488efee11..04887906c91 100644 --- a/doc/user/admin_area/settings/gitaly_timeouts.md +++ b/doc/user/admin_area/settings/gitaly_timeouts.md @@ -8,23 +8,20 @@ type: reference # Gitaly timeouts **(FREE SELF)** [Gitaly](../../../administration/gitaly/index.md) timeouts are configurable. The timeouts can be -configured to make sure that long running Gitaly calls don't needlessly take up resources. +configured to make sure that long-running Gitaly calls don't needlessly take up resources. To access Gitaly timeout settings: 1. On the top bar, select **Menu >** **{admin}** **Admin**. 1. On the left sidebar, select **Settings > Preferences**. -1. Expand the **Gitaly** section. +1. Expand the **Gitaly timeouts** section. ## Available timeouts -The following timeouts can be modified: +The following timeouts are available. -- **Default Timeout Period**. This timeout is the default for most Gitaly calls. It should be shorter than the - worker timeout that can be configured for [Puma](https://docs.gitlab.com/omnibus/settings/puma.html#puma-settings). - Used to make sure that Gitaly calls made within a web request cannot exceed the entire request timeout. - Defaults to 55 seconds. - -- **Fast Timeout Period**. This is the timeout for very short Gitaly calls. Defaults to 10 seconds. -- **Medium Timeout Period**. This timeout should be between the default and the fast timeout. - Defaults to 30 seconds. +| Timeout | Default | Description | +|:--------|:-----------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Default | 55 seconds | Timeout for most Gitaly calls (not enforced for `git` `fetch` and `push` operations, or Sidekiq jobs). For example, checking if a repository exists on disk. Makes sure that Gitaly calls made within a web request cannot exceed the entire request timeout. It should be shorter than the worker timeout that can be configured for [Puma](https://docs.gitlab.com/omnibus/settings/puma.html#puma-settings). If a Gitaly call timeout exceeds the worker timeout, the remaining time from the worker timeout is used to avoid having to terminate the worker. | +| Fast | 10 seconds | Timeout for fast Gitaly operations used within requests, sometimes multiple times. For example, checking if a repository exists on disk. If fast operations exceed this threshold, there may be a problem with a storage shard. Failing fast can help maintain the stability of the GitLab instance. | +| Medium | 30 seconds | Timeout for Gitaly operations that should be fast (possibly within requests) but preferably not used multiple times within a request. For example, loading blobs. Timeout that should be set between Default and Fast. | diff --git a/doc/user/group/devops_adoption/index.md b/doc/user/group/devops_adoption/index.md index 6056af1cb80..e6c9a492c2c 100644 --- a/doc/user/group/devops_adoption/index.md +++ b/doc/user/group/devops_adoption/index.md @@ -9,6 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/321083) in GitLab 13.11 as a [Beta feature](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta). > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/333556) in GitLab 14.1. > - The Overview tab [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/330401) in GitLab 14.1. +> - DAST and SAST metrics [added](https://gitlab.com/gitlab-org/gitlab/-/issues/328033) in GitLab 14.1. Prerequisites: @@ -19,16 +20,18 @@ To access Group DevOps Adoption, go to your group and select **Analytics > DevOp Group DevOps Adoption shows you how individual groups and sub-groups within your organization use the following features: - Dev - - Issues - - Merge Requests - Approvals - Code owners + - Issues + - Merge requests - Sec + - DAST + - SAST - Scans - Ops - - Runners - - Pipelines - Deployments + - Pipelines + - Runners When managing groups in the UI, you can add your sub-groups with the **Add sub-group to table** button, in the top right hand section of your Groups pages. diff --git a/doc/user/markdown.md b/doc/user/markdown.md index db2d6846b7c..809eaf1b8fd 100644 --- a/doc/user/markdown.md +++ b/doc/user/markdown.md @@ -507,7 +507,8 @@ This example links to `<wiki_root>/miscellaneous.md`: GitLab Flavored Markdown renders GitLab-specific references. For example, you can reference an issue, a commit, a team member, or even an entire project team. GitLab Flavored Markdown turns -that reference into a link so you can navigate between them. +that reference into a link so you can navigate between them. All references to namespaces or +projects must use lower-case characters. Additionally, GitLab Flavored Markdown recognizes certain cross-project references and also has a shorthand version to reference other projects from the same namespace. |