diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/administration/auth/smartcard.md | 5 | ||||
| -rw-r--r-- | doc/administration/geo/replication/object_storage.md | 18 | ||||
| -rw-r--r-- | doc/administration/geo/replication/security_review.md | 68 | ||||
| -rw-r--r-- | doc/administration/housekeeping.md | 11 | ||||
| -rw-r--r-- | doc/administration/reference_architectures/troubleshooting.md | 2 | ||||
| -rw-r--r-- | doc/administration/whats-new.md | 18 | ||||
| -rw-r--r-- | doc/api/settings.md | 1 | ||||
| -rw-r--r-- | doc/development/usage_ping/dictionary.md | 24 | ||||
| -rw-r--r-- | doc/install/installation.md | 5 | ||||
| -rw-r--r-- | doc/update/upgrading_from_source.md | 7 | ||||
| -rw-r--r-- | doc/user/admin_area/settings/index.md | 1 | ||||
| -rw-r--r-- | doc/user/analytics/index.md | 8 |
12 files changed, 105 insertions, 63 deletions
diff --git a/doc/administration/auth/smartcard.md b/doc/administration/auth/smartcard.md index 4fe69d0160e..07c29984552 100644 --- a/doc/administration/auth/smartcard.md +++ b/doc/administration/auth/smartcard.md @@ -108,6 +108,11 @@ attribute. As a prerequisite, you must use an LDAP server that: - Supports the `certificateExactMatch` matching rule. - Has the certificate stored in the `userCertificate` attribute. +NOTE: +Active Directory doesn't support the `certificateExactMatch` matching rule so +[it is not supported at this time](https://gitlab.com/gitlab-org/gitlab/-/issues/327491). For +more information, see [the relevant issue](https://gitlab.com/gitlab-org/gitlab/-/issues/328074). + ## Configure GitLab for smartcard authentication **For Omnibus installations** diff --git a/doc/administration/geo/replication/object_storage.md b/doc/administration/geo/replication/object_storage.md index ad419f999b3..7dd831092a3 100644 --- a/doc/administration/geo/replication/object_storage.md +++ b/doc/administration/geo/replication/object_storage.md @@ -9,9 +9,9 @@ type: howto Geo can be used in combination with Object Storage (AWS S3, or other compatible object storage). -Currently, **secondary** nodes can use either: +Currently, **secondary** sites can use either: -- The same storage bucket as the **primary** node. +- The same storage bucket as the **primary** site. - A replicated storage bucket. To have: @@ -28,13 +28,13 @@ To have: WARNING: This is a [**beta** feature](https://about.gitlab.com/handbook/product/#beta) and is not ready yet for production use at any scale. The main limitations are a lack of testing at scale and no verification of any replicated data. -**Secondary** nodes can replicate files stored on the **primary** node regardless of +**Secondary** sites can replicate files stored on the **primary** site regardless of whether they are stored on the local file system or in object storage. To enable GitLab replication, you must: 1. Go to **Admin Area > Geo**. -1. Press **Edit** on the **secondary** node. +1. Press **Edit** on the **secondary** site. 1. In the **Synchronization Settings** section, find the **Allow this secondary node to replicate content on Object Storage** checkbox to enable it. @@ -46,7 +46,7 @@ For CI job artifacts, there is similar documentation to configure For user uploads, there is similar documentation to configure [upload object storage](../../uploads.md#using-object-storage) -If you want to migrate the **primary** node's files to object storage, you can +If you want to migrate the **primary** site's files to object storage, you can configure the **secondary** in a few ways: - Use the exact same object storage. @@ -57,15 +57,15 @@ configure the **secondary** in a few ways: GitLab does not currently support the case where both: -- The **primary** node uses local storage. -- A **secondary** node uses object storage. +- The **primary** site uses local storage. +- A **secondary** site uses object storage. ## Third-party replication services When using Amazon S3, you can use [CRR](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) to -have automatic replication between the bucket used by the **primary** node and -the bucket used by **secondary** nodes. +have automatic replication between the bucket used by the **primary** site and +the bucket used by **secondary** sites. If you are using Google Cloud Storage, consider using [Multi-Regional Storage](https://cloud.google.com/storage/docs/storage-classes#multi-regional). diff --git a/doc/administration/geo/replication/security_review.md b/doc/administration/geo/replication/security_review.md index abb84b95623..f84d7a2171d 100644 --- a/doc/administration/geo/replication/security_review.md +++ b/doc/administration/geo/replication/security_review.md @@ -36,7 +36,7 @@ from [owasp.org](https://owasp.org/). - The GitLab model of sensitivity is centered around public vs. internal vs. private projects. Geo replicates them all indiscriminately. "Selective sync" exists for files and repositories (but not database content), which would permit - only less-sensitive projects to be replicated to a **secondary** node if desired. + only less-sensitive projects to be replicated to a **secondary** site if desired. - See also: [GitLab data classification policy](https://about.gitlab.com/handbook/engineering/security/data-classification-standard.html). ### What data backup and retention requirements have been defined for the application? @@ -48,18 +48,18 @@ from [owasp.org](https://owasp.org/). ### Who are the application's end‐users? -- **Secondary** nodes are created in regions that are distant (in terms of - Internet latency) from the main GitLab installation (the **primary** node). They are - intended to be used by anyone who would ordinarily use the **primary** node, who finds - that the **secondary** node is closer to them (in terms of Internet latency). +- **Secondary** sites are created in regions that are distant (in terms of + Internet latency) from the main GitLab installation (the **primary** site). They are + intended to be used by anyone who would ordinarily use the **primary** site, who finds + that the **secondary** site is closer to them (in terms of Internet latency). ### How do the end‐users interact with the application? -- **Secondary** nodes provide all the interfaces a **primary** node does +- **Secondary** sites provide all the interfaces a **primary** site does (notably a HTTP/HTTPS web application, and HTTP/HTTPS or SSH Git repository access), but is constrained to read-only activities. The principal use case is - envisioned to be cloning Git repositories from the **secondary** node in favor of the - **primary** node, but end-users may use the GitLab web interface to view projects, + envisioned to be cloning Git repositories from the **secondary** site in favor of the + **primary** site, but end-users may use the GitLab web interface to view projects, issues, merge requests, snippets, etc. ### What security expectations do the end‐users have? @@ -67,10 +67,10 @@ from [owasp.org](https://owasp.org/). - The replication process must be secure. It would typically be unacceptable to transmit the entire database contents or all files and repositories across the public Internet in plaintext, for instance. -- **Secondary** nodes must have the same access controls over its content as the - **primary** node - unauthenticated users must not be able to gain access to privileged - information on the **primary** node by querying the **secondary** node. -- Attackers must not be able to impersonate the **secondary** node to the **primary** node, and +- **Secondary** sites must have the same access controls over its content as the + **primary** site - unauthenticated users must not be able to gain access to privileged + information on the **primary** site by querying the **secondary** site. +- Attackers must not be able to impersonate the **secondary** site to the **primary** site, and thus gain access to privileged information. ## Administrators @@ -86,7 +86,7 @@ from [owasp.org](https://owasp.org/). ### What administrative capabilities does the application offer? -- **Secondary** nodes may be added, modified, or removed by users with +- **Secondary** sites may be added, modified, or removed by users with administrative access. - The replication process may be controlled (start/stop) via the Sidekiq administrative controls. @@ -95,9 +95,9 @@ from [owasp.org](https://owasp.org/). ### What details regarding routing, switching, firewalling, and load‐balancing have been defined? -- Geo requires the **primary** node and **secondary** node to be able to communicate with each - other across a TCP/IP network. In particular, the **secondary** nodes must be able to - access HTTP/HTTPS and PostgreSQL services on the **primary** node. +- Geo requires the **primary** site and **secondary** site to be able to communicate with each + other across a TCP/IP network. In particular, the **secondary** sites must be able to + access HTTP/HTTPS and PostgreSQL services on the **primary** site. ### What core network devices support the application? @@ -105,9 +105,9 @@ from [owasp.org](https://owasp.org/). ### What network performance requirements exist? -- Maximum replication speeds between **primary** node and **secondary** node is limited by the +- Maximum replication speeds between **primary** site and **secondary** site is limited by the available bandwidth between sites. No hard requirements exist - time to complete - replication (and ability to keep up with changes on the **primary** node) is a function + replication (and ability to keep up with changes on the **primary** site) is a function of the size of the data set, tolerance for latency, and available network capacity. @@ -189,9 +189,9 @@ from [owasp.org](https://owasp.org/). ### How will database connection strings, encryption keys, and other sensitive components be stored, accessed, and protected from unauthorized detection? - There are some Geo-specific values. Some are shared secrets which must be - securely transmitted from the **primary** node to the **secondary** node at setup time. Our - documentation recommends transmitting them from the **primary** node to the system - administrator via SSH, and then back out to the **secondary** node in the same manner. + securely transmitted from the **primary** site to the **secondary** site at setup time. Our + documentation recommends transmitting them from the **primary** site to the system + administrator via SSH, and then back out to the **secondary** site in the same manner. In particular, this includes the PostgreSQL replication credentials and a secret key (`db_key_base`) which is used to decrypt certain columns in the database. The `db_key_base` secret is stored unencrypted on the file system, in @@ -205,25 +205,25 @@ from [owasp.org](https://owasp.org/). - Data is entered via the web application exposed by GitLab itself. Some data is also entered using system administration commands on the GitLab servers (e.g., `gitlab-ctl set-primary-node`). -- **Secondary** nodes also receive inputs via PostgreSQL streaming replication from the **primary** node. +- **Secondary** sites also receive inputs via PostgreSQL streaming replication from the **primary** site. ### What data output paths does the application support? -- **Primary** nodes output via PostgreSQL streaming replication to the **secondary** node. +- **Primary** sites output via PostgreSQL streaming replication to the **secondary** site. Otherwise, principally via the web application exposed by GitLab itself, and via SSH `git clone` operations initiated by the end-user. ### How does data flow across the application's internal components? -- **Secondary** nodes and **primary** nodes interact via HTTP/HTTPS (secured with JSON web +- **Secondary** sites and **primary** sites interact via HTTP/HTTPS (secured with JSON web tokens) and via PostgreSQL streaming replication. -- Within a **primary** node or **secondary** node, the SSOT is the file system and the database - (including Geo tracking database on **secondary** node). The various internal components +- Within a **primary** site or **secondary** site, the SSOT is the file system and the database + (including Geo tracking database on **secondary** site). The various internal components are orchestrated to make alterations to these stores. ### What data input validation requirements have been defined? -- **Secondary** nodes must have a faithful replication of the **primary** node's data. +- **Secondary** sites must have a faithful replication of the **primary** site's data. ### What data does the application store and how? @@ -231,11 +231,11 @@ from [owasp.org](https://owasp.org/). ### What data is or may need to be encrypted and what key management requirements have been defined? -- Neither **primary** nodes or **secondary** nodes encrypt Git repository or file system data at +- Neither **primary** sites or **secondary** sites encrypt Git repository or file system data at rest. A subset of database columns are encrypted at rest using the `db_otp_key`. - A static secret shared across all hosts in a GitLab deployment. - In transit, data should be encrypted, although the application does permit - communication to proceed unencrypted. The two main transits are the **secondary** node's + communication to proceed unencrypted. The two main transits are the **secondary** site's replication process for PostgreSQL, and for Git repositories/files. Both should be protected using TLS, with the keys for that managed via Omnibus per existing configuration for end-user access to GitLab. @@ -253,19 +253,19 @@ from [owasp.org](https://owasp.org/). ### What user privilege levels does the application support? -- Geo adds one type of privilege: **secondary** nodes can access a special Geo API to +- Geo adds one type of privilege: **secondary** sites can access a special Geo API to download files over HTTP/HTTPS, and to clone repositories using HTTP/HTTPS. ### What user identification and authentication requirements have been defined? -- **Secondary** nodes identify to Geo **primary** nodes via OAuth or JWT authentication +- **Secondary** sites identify to Geo **primary** sites via OAuth or JWT authentication based on the shared database (HTTP access) or a PostgreSQL replication user (for database replication). The database replication also requires IP-based access controls to be defined. ### What user authorization requirements have been defined? -- **Secondary** nodes must only be able to *read* data. They are not currently able to mutate data on the **primary** node. +- **Secondary** sites must only be able to *read* data. They are not currently able to mutate data on the **primary** site. ### What session management requirements have been defined? @@ -279,9 +279,9 @@ from [owasp.org](https://owasp.org/). ### What access requirements have been defined for URI and Service calls? -- **Secondary** nodes make many calls to the **primary** node's API. This is how file +- **Secondary** sites make many calls to the **primary** site's API. This is how file replication proceeds, for instance. This endpoint is only accessible with a JWT token. -- The **primary** node also makes calls to the **secondary** node to get status information. +- The **primary** site also makes calls to the **secondary** site to get status information. ## Application Monitoring diff --git a/doc/administration/housekeeping.md b/doc/administration/housekeeping.md index 0e24ab40157..82891e68a0f 100644 --- a/doc/administration/housekeeping.md +++ b/doc/administration/housekeeping.md @@ -4,9 +4,10 @@ group: Distribution 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/#assignments --- -# Housekeeping +# Housekeeping **(FREE)** -> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/3041) in GitLab 8.4. +GitLab supports and automates housekeeping tasks within your current repository, +such as compressing file revisions and removing unreachable objects. ## Automatic housekeeping @@ -37,9 +38,11 @@ the `pushes_since_gc` value is 200 a `git gc` runs. Housekeeping also [removes unreferenced LFS files](../raketasks/cleanup.md#remove-unreferenced-lfs-files) from your project on the same schedule as the `git gc` operation, freeing up storage space for your project. -You can find this option under your project's **Settings > General > Advanced**. +To manually start the housekeeping process: - +1. In your project, go to **Settings > General**. +1. Expand the **Advanced** section. +1. Select **Run housekeeping**. ## How housekeeping handles pool repositories diff --git a/doc/administration/reference_architectures/troubleshooting.md b/doc/administration/reference_architectures/troubleshooting.md index e5d65264a5c..d5f57965a80 100644 --- a/doc/administration/reference_architectures/troubleshooting.md +++ b/doc/administration/reference_architectures/troubleshooting.md @@ -4,7 +4,7 @@ group: Distribution 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/#assignments --- -# Troubleshooting a reference architecture setup +# Troubleshooting a reference architecture setup **(FREE SELF)** This page serves as the troubleshooting documentation if you followed one of the [reference architectures](index.md#reference-architectures). diff --git a/doc/administration/whats-new.md b/doc/administration/whats-new.md index 4cbb0b854ae..a5e3a232890 100644 --- a/doc/administration/whats-new.md +++ b/doc/administration/whats-new.md @@ -19,11 +19,23 @@ feature list, the feature list is tailored to your subscription type: - Features only available to self-managed installations are not shown on GitLab.com. - Features only available on GitLab.com are not shown to self-managed installations. -The **What's new** feature cannot be disabled, but -[is planned](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/59011) for a future release. - ## Self-managed installations Due to our release post process, the content for **What's new** is not yet finalized when a new version (`.0` release) is cut. The updated **What's new** is included in the first patch release, such as `13.10.1`. + +## Configure What's new variant + +You can configure the What's new variant: + +1. Navigate to **Admin Area > Settings > Preferences**, then expand **What's new**. +1. Choose one of the following options: + + | Option | Description | + | ------ | ----------- | + | Enable What's new: All tiers | What's new presents new features from all tiers to help you keep track of all new features. | + | Enable What's new: Current tier only | What's new presents new features for your current subscription tier, while hiding new features not available to your subscription tier. | + | Disable What's new | What's new is disabled and can no longer be viewed. | + +1. Save your changes. diff --git a/doc/api/settings.md b/doc/api/settings.md index 146cd1628ff..1ba6ba2e42a 100644 --- a/doc/api/settings.md +++ b/doc/api/settings.md @@ -410,6 +410,7 @@ listed in the descriptions of the relevant settings. | `user_oauth_applications` | boolean | no | Allow users to register any application to use GitLab as an OAuth provider. | | `user_show_add_ssh_key_message` | boolean | no | When set to `false` disable the "You won't be able to pull or push project code via SSH" warning shown to users with no uploaded SSH key. | | `version_check_enabled` | boolean | no | Let GitLab inform you when an update is available. | +| `whats_new_variant` | string | no | What's new variant, possible values: `all_tiers`, `current_tier`, and `disabled`. | | `web_ide_clientside_preview_enabled` | boolean | no | Live Preview (allow live previews of JavaScript projects in the Web IDE using CodeSandbox Live Preview). | | `wiki_page_max_content_bytes` | integer | no | Maximum wiki page content size in **bytes**. Default: 52428800 Bytes (50 MB). The minimum value is 1024 bytes. | diff --git a/doc/development/usage_ping/dictionary.md b/doc/development/usage_ping/dictionary.md index d69de6a6e9e..d640b6f8023 100644 --- a/doc/development/usage_ping/dictionary.md +++ b/doc/development/usage_ping/dictionary.md @@ -7592,6 +7592,30 @@ Status: `data_available` Tiers: +### `redis_hll_counters.analytics.users_viewing_analytics_group_devops_adoption_monthly` + +Counts visits to DevOps Adoption page per month + +[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_28d/20210419105414_users_viewing_analytics_group_devops_adoption_monthly.yml) + +Group: `group::optimize` + +Status: `implemented` + +Tiers: `premium`, `ultimate` + +### `redis_hll_counters.analytics.users_viewing_analytics_group_devops_adoption_weekly` + +Counts visits to DevOps Adoption page per week + +[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_7d/20210419105408_users_viewing_analytics_group_devops_adoption_weekly.yml) + +Group: `group::optimize` + +Status: `implemented` + +Tiers: `premium`, `ultimate` + ### `redis_hll_counters.ci_secrets_management.i_ci_secrets_management_vault_build_created_monthly` Missing description diff --git a/doc/install/installation.md b/doc/install/installation.md index eb8c3784cfa..37ab4ccbcd2 100644 --- a/doc/install/installation.md +++ b/doc/install/installation.md @@ -276,10 +276,7 @@ we need to install through the following commands: curl --location "https://deb.nodesource.com/setup_14.x" | sudo bash - sudo apt-get install -y nodejs -curl --silent --show-error "https://dl.yarnpkg.com/debian/pubkey.gpg" | sudo apt-key add - -echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list -sudo apt-get update -sudo apt-get install yarn +npm install --global yarn ``` Visit the official websites for [node](https://nodejs.org/en/download/package-manager/) and [yarn](https://classic.yarnpkg.com/en/docs/install/) if you have any trouble with these steps. diff --git a/doc/update/upgrading_from_source.md b/doc/update/upgrading_from_source.md index 33ae9befd16..93d2c2cb288 100644 --- a/doc/update/upgrading_from_source.md +++ b/doc/update/upgrading_from_source.md @@ -90,10 +90,9 @@ dependencies. In Debian or Ubuntu: ```shell -curl --silent --show-error "https://dl.yarnpkg.com/debian/pubkey.gpg" | sudo apt-key add - -echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list -sudo apt-get update -sudo apt-get install yarn +sudo apt-get remove yarn + +npm install --global yarn ``` More information can be found on the [Yarn website](https://classic.yarnpkg.com/en/docs/install). diff --git a/doc/user/admin_area/settings/index.md b/doc/user/admin_area/settings/index.md index 023c4548d73..a1f4c6a06e2 100644 --- a/doc/user/admin_area/settings/index.md +++ b/doc/user/admin_area/settings/index.md @@ -108,6 +108,7 @@ Access the default page for admin area settings by navigating to **Admin Area > | Option | Description | | ------ | ----------- | | [Email](email.md) | Various email settings. | +| [What's new](../../../administration/whats-new.md) | Configure What's new drawer and content. | | [Help page](help_page.md) | Help page text and support page URL. | | [Pages](../../../administration/pages/index.md#custom-domain-verification) | Size and domain settings for static websites | | [Real-time features](../../../administration/polling.md) | Change this value to influence how frequently the GitLab UI polls for updates. | diff --git a/doc/user/analytics/index.md b/doc/user/analytics/index.md index 6e3c9cf7a5f..e6f7b6750b3 100644 --- a/doc/user/analytics/index.md +++ b/doc/user/analytics/index.md @@ -10,7 +10,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w When we describe GitLab analytics, we use the following terms: -- Cycle time: The duration of your value stream, from start to finish. Often displayed in combination with "lead time." GitLab measures cycle time from issue creation to issue close. GitLab displays cycle time in [Value Stream Analytics](value_stream_analytics.md). +- Cycle time: The duration of your value stream, from start to finish. Often displayed in combination with "lead time." GitLab measures cycle time from issue creation to issue close. GitLab displays cycle time in [group-level Value Stream Analytics](../group/value_stream_analytics/index.md). - DORA (DevOps Research and Assessment) ["Four Keys"](https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance): - Speed - Deployment Frequency: How often an organization successfully releases to production. @@ -19,11 +19,11 @@ as described in ([Measuring DevOps Performance](https://devops.com/measuring-dev - Stability - Change Failure Rate: The percentage of deployments causing a failure in production. - Time to Restore Service: How long it takes an organization to recover from a failure in production. +- Lead time: The duration of the work itself. Often displayed in combination with "cycle time." GitLab measures from issue first merge request creation to issue close. Note: Work started before the creation of the first merge request. We [plan to start measuring from "issue first commit"](https://gitlab.com/gitlab-org/gitlab/-/issues/328459) as a better proxy, although still imperfect. GitLab displays lead time in [group-level Value Stream Analytics](../group/value_stream_analytics/index.md). - MTTC (Mean Time to Change): The average duration between idea and delivery. GitLab measures MTTC from issue creation to the issue's latest related merge request's deployment to production. - MTTD (Mean Time to Detect): The average duration that a bug goes undetected in production. GitLab measures MTTD from deployment of bug to issue creation. - MTTM (Mean Time To Merge): The average lifespan of a merge request. GitLab measures MTTM from merge request creation to merge request merge (and closed/un-merged merge requests are excluded). For more information, see [Merge Request Analytics](merge_request_analytics.md). - MTTR (Mean Time to Recover/Repair/Resolution/Resolve/Restore): The average duration that a bug is not fixed in production. GitLab measures MTTR from deployment of bug to deployment of fix. -- Lead time: The duration of the work itself. Often displayed in combination with "cycle time." GitLab measures from issue first merge request creation to issue close. Note: Work started before the creation of the first merge request. We plan to start measuring from "issue first commit" as a better proxy, although still imperfect. GitLab displays lead time in [Value Stream Analytics](value_stream_analytics.md). - Throughput: The number of issues closed or merge requests merged (not closed) in some period of time. Often measured per sprint. GitLab displays merge request throughput in [Merge Request Analytics](merge_request_analytics.md). - Value Stream: The entire work process that is followed to deliver value to customers. For example, the [DevOps lifecycle](https://about.gitlab.com/stages-devops-lifecycle/) is a value stream that starts with "plan" and ends with "monitor". GitLab helps you track your value stream using [Value Stream Analytics](value_stream_analytics.md). - Velocity: The total issue burden completed in some period of time. The burden is usually measured in points or weight, often per sprint. For example, your velocity may be "30 points per sprint". GitLab measures velocity as the total points/weight of issues closed in a given period of time. @@ -45,6 +45,7 @@ in one place. The following analytics features are available at the group level: +- [Application Security](../application_security/security_dashboard/#group-security-dashboard). **(ULTIMATE)** - [Contribution](../group/contribution_analytics/index.md). **(PREMIUM)** - [DevOps Adoption](../group/devops_adoption/index.md). **(ULTIMATE)** - [Insights](../group/insights/index.md). **(ULTIMATE)** @@ -52,12 +53,12 @@ The following analytics features are available at the group level: - [Productivity](productivity_analytics.md). **(PREMIUM)** - [Repositories](../group/repositories_analytics/index.md). **(PREMIUM)** - [Value Stream](../group/value_stream_analytics/index.md). **(PREMIUM)** -- [Application Security](../application_security/security_dashboard/#group-security-dashboard). **(ULTIMATE)** ## Project-level analytics The following analytics features are available at the project level: +- [Application Security](../application_security/security_dashboard/#project-security-dashboard). **(ULTIMATE)** - [CI/CD](ci_cd_analytics.md). **(FREE)** - [Code Review](code_review_analytics.md). **(PREMIUM)** - [Insights](../project/insights/index.md). **(ULTIMATE)** @@ -66,7 +67,6 @@ The following analytics features are available at the project level: [feature flag](../../development/feature_flags/index.md#enabling-a-feature-flag-locally-in-development). **(PREMIUM)** - [Repository](repository_analytics.md). **(FREE)** - [Value Stream](value_stream_analytics.md). **(FREE)** -- [Application Security](../application_security/security_dashboard/#project-security-dashboard). **(ULTIMATE)** ## User-configurable analytics |