diff --git a/danger/specialization_labels/Dangerfile b/danger/specialization_labels/Dangerfile index ec79611d93d..8da00fcd6d9 100644 --- a/danger/specialization_labels/Dangerfile +++ b/danger/specialization_labels/Dangerfile @@ -15,8 +15,14 @@ SPECIALIZATIONS = { labels_to_add = project_helper.changes_by_category.each_with_object([]) do |(category, _changes), memo| label = SPECIALIZATIONS[category] + next unless label + next if gitlab.mr_labels.include?(label) - memo << label if label && !gitlab.mr_labels.include?(label) + # Don't override already-set scoped labels. + label_scope = label.split('::')[0...-1].join('::') + next if !label_scope.empty? && gitlab.mr_labels.any? { |mr_label| mr_label.start_with?(label_scope) } + + memo << label end project_helper.labels_to_add.concat(labels_to_add) if labels_to_add.any? diff --git a/db/post_migrate/20211018123316_remove_not_null_constraint_and_default_for_public_email.rb b/db/post_migrate/20211018123316_remove_not_null_constraint_and_default_for_public_email.rb new file mode 100644 index 00000000000..72a5970b6d7 --- /dev/null +++ b/db/post_migrate/20211018123316_remove_not_null_constraint_and_default_for_public_email.rb @@ -0,0 +1,15 @@ +# frozen_string_literal: true + +class RemoveNotNullConstraintAndDefaultForPublicEmail < Gitlab::Database::Migration[1.0] + enable_lock_retries! + + def up + change_column_null :users, :public_email, true + change_column_default :users, :public_email, from: '', to: nil + end + + def down + # There may now be nulls in the table, so we cannot re-add the constraint here. + change_column_default :users, :public_email, from: nil, to: '' + end +end diff --git a/db/schema_migrations/20211018123316 b/db/schema_migrations/20211018123316 new file mode 100644 index 00000000000..37bf0b261f1 --- /dev/null +++ b/db/schema_migrations/20211018123316 @@ -0,0 +1 @@ +fcee17f25ad3a8b6fb56c23b72978f4a6952200264d285b9e3df4b5e7733e8f6 \ No newline at end of file diff --git a/db/structure.sql b/db/structure.sql index e8963c58955..b76bf40fdff 100644 --- a/db/structure.sql +++ b/db/structure.sql @@ -20194,7 +20194,7 @@ CREATE TABLE users ( encrypted_otp_secret_salt character varying, otp_required_for_login boolean DEFAULT false NOT NULL, otp_backup_codes text, - public_email character varying DEFAULT ''::character varying NOT NULL, + public_email character varying, dashboard integer DEFAULT 0, project_view integer DEFAULT 0, consumed_timestep integer, diff --git a/doc/administration/get_started.md b/doc/administration/get_started.md index 6d08b0037b6..bff2aee1d2d 100644 --- a/doc/administration/get_started.md +++ b/doc/administration/get_started.md @@ -231,7 +231,7 @@ Rate limits also improve the security of your application. ### Configure rate limits for self-managed GitLab -You can make changes to your default rate limits from the Admin Area. For more information about configuration, see the [Admin Area page](../security/rate_limits.md#admin-area-settings). +You can make changes to your default rate limits from the Admin Area. For more information about configuration, see the [Admin Area page](../security/rate_limits.md#configurable-limits). - Define [issues rate limits](../user/admin_area/settings/rate_limit_on_issues_creation.md) to set a maximum number of issue creation requests per minute, per user. - Enforce [user and IP rate limits](../user/admin_area/settings/user_and_ip_rate_limits.md) for unauthenticated web requests. @@ -249,7 +249,7 @@ Rate limits also improve the security of your application. ### Configure rate limits for GitLab SaaS -You can make changes to your default rate limits from the Admin Area. For more information about configuration, see the [Admin Area page](../security/rate_limits.md#admin-area-settings). +You can make changes to your default rate limits from the Admin Area. For more information about configuration, see the [Admin Area page](../security/rate_limits.md#configurable-limits). - Review the rate limit page. - Read our [API page](../api/index.md) for more information about API and rate limiting. diff --git a/doc/administration/instance_limits.md b/doc/administration/instance_limits.md index c7481abc84e..f6de760b0d1 100644 --- a/doc/administration/instance_limits.md +++ b/doc/administration/instance_limits.md @@ -143,6 +143,9 @@ This only applies to project and group webhooks. Calls over the rate limit are logged into `auth.log`. +To set this limit for a self-managed installation, run the following in the +[GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session): + ```ruby # If limits don't exist for the default plan, you can create one with: # Plan.default.create_limits! diff --git a/doc/security/rate_limits.md b/doc/security/rate_limits.md index 3826c02a201..9d49297c9de 100644 --- a/doc/security/rate_limits.md +++ b/doc/security/rate_limits.md @@ -27,7 +27,7 @@ Most cases can be mitigated by limiting the rate of requests from a single IP ad Most [brute-force attacks](https://en.wikipedia.org/wiki/Brute-force_attack) are similarly mitigated by a rate limit. -## Admin Area settings +## Configurable limits You can set these rate limits in the Admin Area of your instance: @@ -42,6 +42,10 @@ You can set these rate limits in the Admin Area of your instance: - [Files API rate limits](../user/admin_area/settings/files_api_rate_limits.md) - [Deprecated API rate limits](../user/admin_area/settings/deprecated_api_rate_limits.md) +You can set these rate limits using the Rails console: + +- [Webhook rate limit](../administration/instance_limits.md#webhook-rate-limit) + ## Failed authentication ban for Git and container registry GitLab returns HTTP status code `403` for 1 hour, if 30 failed authentication requests were received diff --git a/doc/user/analytics/index.md b/doc/user/analytics/index.md index c01788f4fc4..0cc21e3f390 100644 --- a/doc/user/analytics/index.md +++ b/doc/user/analytics/index.md @@ -6,65 +6,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w # Analyze GitLab usage **(FREE)** -## Definitions - -When we describe GitLab analytics, we use the following terms: - -- **Cycle time:** The duration of only the execution work. Cycle time is often displayed in combination with the lead time, which is longer than the cycle time. GitLab measures cycle time from the earliest commit of a [linked issue's merge request](../project/issues/crosslinking_issues.md) to when that issue is closed. The cycle time approach underestimates the lead time because merge request creation is always later than commit time. GitLab displays cycle time in [group-level Value Stream Analytics](../group/value_stream_analytics/index.md) and [project-level Value Stream Analytics](../analytics/value_stream_analytics.md). -- **Deploys:** The total number of successful deployments to production in the given time frame (across all applicable projects). GitLab displays deploys in [group-level Value Stream Analytics](../group/value_stream_analytics/index.md) and [project-level Value Stream Analytics](value_stream_analytics.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/Velocity** - - - **Deployment frequency:** The relative frequency of successful deployments to production - (hourly, daily, weekly, monthly, or yearly). - This effectively measures how often you are delivering value to end users. A higher deployment - frequency means you are able to get feedback and iterate more quickly in delivering - improvements and features faster. GitLab measures this as the number of deployments to a - [production environment](../../ci/environments/index.md#deployment-tier-of-environments) in - the given time period. - GitLab displays deployment frequency in [group-level Value Stream Analytics](../group/value_stream_analytics/index.md) and [project-level Value Stream Analytics](value_stream_analytics.md). - - **Lead Time for Changes:** The time it takes for a commit to get into production. (1) GitLab - measures this as the median duration between merge request merge and deployment to a - [production environment](../../ci/environments/index.md#deployment-tier-of-environments) for - all MRs deployed in the given time period. This measure under-estimates lead time because - merge time is always later than commit time. The - [standard definition](https://github.com/GoogleCloudPlatform/fourkeys/blob/main/METRICS.md#lead-time-for-changes) uses median commit time. - [An issue exists](https://gitlab.com/gitlab-org/gitlab/-/issues/328459) to start - measuring from "issue first commit" as a better proxy, although still imperfect. - - - **Stability** - - **Change Failure Rate:** The percentage of deployments causing a failure in production. - GitLab measures this as the number of [incidents](../../operations/incident_management/incidents.md) - divided by the number of deployments to a - [production environment](../../ci/environments/index.md#deployment-tier-of-environments) in - the given time period. This assumes: - - - All incidents are related to a production environment. - - Incidents and deployments have a strictly one-to-one relationship (meaning any incident is - related to only one production deployment, and any production deployment is related to no - more than one incident). - - - **Time to Restore Service:** How long it takes an organization to recover from a failure in - production. GitLab measures this as the average time required to close the - [incidents](../../operations/incident_management/incidents.md) in the given time period. - This assumes: - - - All incidents are related to a [production environment](../../ci/environments/index.md#deployment-tier-of-environments). - - Incidents and deployments have a strictly one-to-one relationship (meaning any incident is related to only one production deployment, and any production deployment is related to no more than one incident). - -- **Lead time:** The duration of your value stream, from start to finish. Different from [Lead time for changes](#lead-time-for-changes). Often displayed in combination with "cycle time," which is shorter. GitLab measures lead time from issue creation to issue close. 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. -- **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. - -### Lead time for changes - -"Lead Time for Changes" differs from ordinary "Lead Time" because it "focuses on measuring only the time to deliver a feature once it has been developed", as described in ([Measuring DevOps Performance](https://devops.com/measuring-devops-performance/)). - ## Instance-level analytics > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/12077) in GitLab 12.2. @@ -112,3 +53,76 @@ The following analytics features are available for users to create personalized - [Application Security](../application_security/security_dashboard/#security-center) Be sure to review the documentation page for this feature for GitLab tier requirements. + +## Definitions + +We use the following terms to describe GitLab analytics: + +- **Cycle time:** The duration of only the execution work. Cycle time is often displayed in combination with the lead time, which is longer than the cycle time. GitLab measures cycle time from the earliest commit of a [linked issue's merge request](../project/issues/crosslinking_issues.md) to when that issue is closed. The cycle time approach underestimates the lead time because merge request creation is always later than commit time. GitLab displays cycle time in [group-level Value Stream Analytics](../group/value_stream_analytics/index.md) and [project-level Value Stream Analytics](../analytics/value_stream_analytics.md). +- **Deploys:** The total number of successful deployments to production in the given time frame (across all applicable projects). GitLab displays deploys in [group-level Value Stream Analytics](../group/value_stream_analytics/index.md) and [project-level Value Stream Analytics](value_stream_analytics.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/Velocity** + + - **Deployment frequency:** The relative frequency of successful deployments to production + (hourly, daily, weekly, monthly, or yearly). + This measures how often you are delivering value to end users. A higher deployment + frequency means you are able to get feedback and iterate faster to deliver + improvements and features. GitLab measures this as the number of deployments to a + [production environment](../../ci/environments/index.md#deployment-tier-of-environments) in + the given time period. + GitLab displays deployment frequency in [group-level Value Stream Analytics](../group/value_stream_analytics/index.md) and [project-level Value Stream Analytics](value_stream_analytics.md). + - **Lead Time for Changes:** The time it takes for a commit to get into production. GitLab + measures this as the median duration between merge request merge and deployment to a + [production environment](../../ci/environments/index.md#deployment-tier-of-environments) for + all MRs deployed in the given time period. This measure under estimates lead time because + merge time is always later than commit time. The + [standard definition](https://github.com/GoogleCloudPlatform/fourkeys/blob/main/METRICS.md#lead-time-for-changes) uses median commit time. + [An issue exists](https://gitlab.com/gitlab-org/gitlab/-/issues/328459) to start + measuring from "issue first commit" as a better proxy, although still imperfect. + + - **Stability** + - **Change Failure Rate:** The percentage of deployments causing a failure in production. + GitLab measures this as the number of [incidents](../../operations/incident_management/incidents.md) + divided by the number of deployments to a + [production environment](../../ci/environments/index.md#deployment-tier-of-environments) in + the given time period. This assumes: + + - All incidents are related to a production environment. + - Incidents and deployments have a strictly one-to-one relationship (meaning any incident is + related to only one production deployment, and any production deployment is related to no + more than one incident). + + - **Time to Restore Service:** How long it takes an organization to recover from a failure in + production. GitLab measures this as the average time required to close the + [incidents](../../operations/incident_management/incidents.md) in the given time period. + This assumes: + + - All incidents are related to a [production environment](../../ci/environments/index.md#deployment-tier-of-environments). + - Incidents and deployments have a strictly one-to-one relationship (meaning any incident is related to only one production deployment, and any production deployment is related to no more than one incident). + +- **Lead time:** The duration of your value stream, from start to finish. Different to +[Lead time for changes](#lead-time-for-changes). Often displayed in combination with "cycle time," +which is shorter. GitLab measures lead time from issue creation to issue close. GitLab displays lead +time in [group-level Value Stream Analytics](../group/value_stream_analytics/index.md). +- **Mean Time to Change (MTTC):** 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. +- **Mean Time to Detect (MTTD):** The average duration that a bug goes undetected in production. +GitLab measures MTTD from deployment of bug to issue creation. +- **Mean Time To Merge (MTTM):** 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). +- **Mean Time to Recover/Repair/Resolution/Resolve/Restore (MTTR):** The average duration that a bug +is not fixed in production. GitLab measures MTTR from deployment of bug to deployment of fix. +- **Throughput:** The number of issues closed or merge requests merged (not closed) in a 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 or weight of issues closed in a given period of time. + +## Lead time for changes + +"Lead Time for Changes" differs from "Lead Time" because it "focuses on measuring only the time to +deliver a feature once it has been developed", as described in ([Measuring DevOps Performance](https://devops.com/measuring-devops-performance/)). diff --git a/qa/qa/specs/features/browser_ui/5_package/package_registry/maven_repository_spec.rb b/qa/qa/specs/features/browser_ui/5_package/package_registry/maven_repository_spec.rb index bf1d2a04dba..b993aea8103 100644 --- a/qa/qa/specs/features/browser_ui/5_package/package_registry/maven_repository_spec.rb +++ b/qa/qa/specs/features/browser_ui/5_package/package_registry/maven_repository_spec.rb @@ -1,7 +1,7 @@ # frozen_string_literal: true module QA - RSpec.describe 'Package', :orchestrated, :packages, :reliable, :object_storage do + RSpec.describe 'Package', :orchestrated, :packages, :object_storage do describe 'Maven Repository' do include Runtime::Fixtures