diff --git a/.gitlab/merge_request_templates/Documentation.md b/.gitlab/merge_request_templates/Documentation.md index 10843334aff..a465463f7fc 100644 --- a/.gitlab/merge_request_templates/Documentation.md +++ b/.gitlab/merge_request_templates/Documentation.md @@ -47,5 +47,5 @@ If you aren't sure which tech writer to ask, use [roulette](https://gitlab-org.g - If the content still needs to be edited for topic types, you can create a follow-up issue with the ~"docs-technical-debt" label. - [ ] Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review. -/label ~documentation ~"type::maintenance" ~"docs::improvement" ~"maintenance::refactor" +/label ~documentation ~"type::maintenance" ~"docs::improvement" ~"maintenance::refactor" ~"docs-only" /assign me diff --git a/app/assets/javascripts/ml/model_registry/services/upload_model.js b/app/assets/javascripts/ml/model_registry/services/upload_model.js index 0c1af3ee526..7d70c92c021 100644 --- a/app/assets/javascripts/ml/model_registry/services/upload_model.js +++ b/app/assets/javascripts/ml/model_registry/services/upload_model.js @@ -14,6 +14,11 @@ export const uploadModel = ({ if (!file) { return Promise.resolve(); } + + if (subfolder && subfolder.includes(' ')) { + return Promise.reject(new Error(s__('Mlmodelregistry|Subfolder cannot contain spaces'))); + } + if (!maxAllowedFileSize) { return Promise.resolve(s__('Mlmodelregistry|Provide the max allowed file size')); } diff --git a/app/controllers/concerns/wiki_actions.rb b/app/controllers/concerns/wiki_actions.rb index 0face94d24c..5d45bbd2558 100644 --- a/app/controllers/concerns/wiki_actions.rb +++ b/app/controllers/concerns/wiki_actions.rb @@ -157,6 +157,8 @@ module WikiActions ) elsif show_create_form? handle_create_form + elsif wiki.exists? + render 'shared/wikis/404', status: :not_found else render 'shared/wikis/empty' end diff --git a/app/mailers/emails/imports.rb b/app/mailers/emails/imports.rb index bb6262bfa3e..2fc777eec4c 100644 --- a/app/mailers/emails/imports.rb +++ b/app/mailers/emails/imports.rb @@ -15,13 +15,10 @@ module Emails def bulk_import_complete(user_id, bulk_import_id) user = User.find(user_id) @bulk_import = BulkImport.find(bulk_import_id) - @bulk_import_entity = @bulk_import.parent_group_entity @hostname = @bulk_import.configuration.url - @source_group = @bulk_import_entity.source_full_path title = safe_format( - s_('BulkImport|Import of %{source_group} from %{hostname}'), - hostname: @hostname, - source_group: @source_group + s_('BulkImport|Import from %{hostname} completed'), + hostname: @hostname ) email_with_layout( diff --git a/app/policies/board_policy.rb b/app/policies/board_policy.rb index e2b16249c85..eaffffd68af 100644 --- a/app/policies/board_policy.rb +++ b/app/policies/board_policy.rb @@ -24,6 +24,10 @@ class BoardPolicy < BasePolicy .exists? end + rule { admin }.policy do + enable :create_non_backlog_issues + end + rule { is_group_board & reporter_of_group_projects }.policy do enable :create_non_backlog_issues end diff --git a/app/views/jira_connect/subscriptions/index.html.haml b/app/views/jira_connect/subscriptions/index.html.haml index f66aa0840aa..13b9ea9742f 100644 --- a/app/views/jira_connect/subscriptions/index.html.haml +++ b/app/views/jira_connect/subscriptions/index.html.haml @@ -1,6 +1,5 @@ .js-jira-connect-app{ data: jira_connect_app_data(@subscriptions, @current_jira_installation) } -= webpack_bundle_tag 'performance_bar' if performance_bar_enabled? = webpack_bundle_tag 'jira_connect_app' - add_page_specific_style 'page_bundles/jira_connect', defer: false diff --git a/app/views/notify/bulk_import_complete.html.haml b/app/views/notify/bulk_import_complete.html.haml index 93543c3edd5..68db64c235b 100644 --- a/app/views/notify/bulk_import_complete.html.haml +++ b/app/views/notify/bulk_import_complete.html.haml @@ -3,20 +3,16 @@ - button_style = 'border: 1px solid #694cc0; border-radius: 4px; font-size: 14px; padding: 8px 16px; background-color: #7b58cf; color: #fff; cursor: pointer;' - strong_tag_pair = tag_pair(tag.strong, :strong_open, :strong_close) -- strong_color_tag_pair = tag_pair(tag.strong(style: 'color: #7b58cf'), :strong_color_open, :strong_color_close) - -- destination_group = @bulk_import_entity.full_path_with_fallback +- start_date = l(@bulk_import.created_at.to_date, format: :long) %h1{ style: header_style } = s_('BulkImport|Import completed') %p{ style: text_style } - = safe_format(s_('BulkImport|The import of %{strong_open}%{source_group}%{strong_close} from %{strong_open}%{hostname}%{strong_close} to %{strong_color_open}%{destination_group}%{strong_color_close} is complete. You can view the results of the import.'), + = safe_format(s_('BulkImport|The import you started on %{start_date} from %{strong_open}%{hostname}%{strong_close} has completed. You can now review your import results.'), strong_tag_pair, - strong_color_tag_pair, - source_group: @source_group, hostname: @hostname, - destination_group: destination_group) + start_date: start_date) %p{ style: text_style } = link_to history_import_bulk_import_url(@bulk_import.id), target: '_blank', rel: 'noopener noreferrer' do diff --git a/app/views/notify/bulk_import_complete.text.erb b/app/views/notify/bulk_import_complete.text.erb index a23ad2dd88b..aed0b79b6f7 100644 --- a/app/views/notify/bulk_import_complete.text.erb +++ b/app/views/notify/bulk_import_complete.text.erb @@ -1,7 +1,5 @@ -<% destination_group = @bulk_import_entity.full_path_with_fallback %> - <%= s_('BulkImport|Import completed') %> -<%= safe_format(s_('BulkImport|The import of %{strong_open}%{source_group}%{strong_close} from %{strong_open}%{hostname}%{strong_close} to %{strong_color_open}%{destination_group}%{strong_color_close} is complete. You can view the results of the import.'), strong_open: '', strong_close: '', strong_color_open: '', strong_color_close: '', source_group: @source_group, hostname: @hostname, destination_group: destination_group) %> +<%= safe_format(s_('BulkImport|The import you started on %{start_date} from %{strong_open}%{hostname}%{strong_close} has completed. You can now review your import results.'), strong_open: '', strong_close: '', hostname: @hostname, start_date: l(@bulk_import.created_at.to_date, format: :long)) %> <%= s_('BulkImport|View import results') %>: <%= history_import_bulk_import_url(@bulk_import.id) %> diff --git a/app/views/shared/wikis/404.html.haml b/app/views/shared/wikis/404.html.haml new file mode 100644 index 00000000000..2ebfc1be440 --- /dev/null +++ b/app/views/shared/wikis/404.html.haml @@ -0,0 +1,20 @@ +- page_title _("Wiki") +- @right_sidebar = true +- add_page_specific_style 'page_bundles/wiki' + +- if @error.present? + = render Pajamas::AlertComponent.new(alert_options: { id: 'error_explanation', class: 'gl-mb-3'}, + dismissible: false, + variant: :danger) do |c| + - c.with_body do + %ul.gl-pl-4 + = @error + += render Pajamas::EmptyStateComponent.new(svg_path: 'illustrations/empty-state/empty-wiki-md.svg', + title: _('Sorry, this page doesn\'t exist'), + empty_state_options: { data: { testid: 'wiki-404' } }) do |c| + + - c.with_description do + = s_('Wiki|Use the sidebar to find a different page.') + += render 'shared/wikis/sidebar' diff --git a/data/deprecations/16-9-sast-analyzer-consolidation.yml b/data/deprecations/16-9-sast-analyzer-consolidation.yml index 62c8b2f18bf..c80d8aa5398 100644 --- a/data/deprecations/16-9-sast-analyzer-consolidation.yml +++ b/data/deprecations/16-9-sast-analyzer-consolidation.yml @@ -12,11 +12,11 @@ In GitLab 17.0, we will: 1. Remove a set of language-specific analyzers from the [SAST CI/CD template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml) and replace their coverage with [GitLab-supported detection rules](https://docs.gitlab.com/ee/user/application_security/sast/rules.html) in the [Semgrep-based analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep). The following analyzers are now deprecated and will reach End of Support in GitLab 17.0: - 1. [Brakeman](https://gitlab.com/gitlab-org/security-products/analyzers/brakeman) (Ruby, Ruby on Rails) - 1. [Flawfinder](https://gitlab.com/gitlab-org/security-products/analyzers/flawfinder) (C, C++) - 1. [MobSF](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf) (Android, iOS) - 1. [NodeJS Scan](https://gitlab.com/gitlab-org/security-products/analyzers/nodejs-scan) (Node.js) - 1. [PHPCS Security Audit](https://gitlab.com/gitlab-org/security-products/analyzers/phpcs-security-audit) (PHP) + 1. [Brakeman](https://gitlab.com/gitlab-org/security-products/analyzers/brakeman) (Ruby, Ruby on Rails) + 1. [Flawfinder](https://gitlab.com/gitlab-org/security-products/analyzers/flawfinder) (C, C++) + 1. [MobSF](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf) (Android, iOS) + 1. [NodeJS Scan](https://gitlab.com/gitlab-org/security-products/analyzers/nodejs-scan) (Node.js) + 1. [PHPCS Security Audit](https://gitlab.com/gitlab-org/security-products/analyzers/phpcs-security-audit) (PHP) 1. Change the [SAST CI/CD template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml) to stop running the [SpotBugs-based analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs) for Kotlin and Scala code. These languages will instead be scanned using [GitLab-supported detection rules](https://docs.gitlab.com/ee/user/application_security/sast/rules.html) in the [Semgrep-based analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep). Effective immediately, the deprecated analyzers will receive only security updates; other routine improvements or updates are not guaranteed. diff --git a/doc/administration/geo/index.md b/doc/administration/geo/index.md index 13d95f86cb3..05b73918c8b 100644 --- a/doc/administration/geo/index.md +++ b/doc/administration/geo/index.md @@ -58,6 +58,8 @@ the difference between Geo and Gitaly Cluster, see [Comparison to Geo](../gitaly ## How it works +This is a brief summary of how Geo works in your GitLab environment. For a more detailed information, see the [Geo Development page](/ee/development/geo.md). + Your Geo instance can be used for cloning and fetching projects, in addition to reading any data. This makes working with large repositories over large distances much faster. ![Geo overview](replication/img/geo_overview.png) diff --git a/doc/administration/license.md b/doc/administration/license.md index d3c6fbccd37..661487a0cda 100644 --- a/doc/administration/license.md +++ b/doc/administration/license.md @@ -106,9 +106,9 @@ You may have connectivity issues due to the following reasons: - **Firewall settings**: - Confirm that GitLab instance can establish an encrypted connection to `https://customers.gitlab.com` on port 443. - ```shell - curl --verbose "https://customers.gitlab.com/" - ``` + ```shell + curl --verbose "https://customers.gitlab.com/" + ``` - If the curl command returns an error, either: - Check your firewall or proxy. The domain `https://customers.gitlab.com` is diff --git a/doc/administration/package_information/supported_os.md b/doc/administration/package_information/supported_os.md index 46305c4960d..8f720b3d953 100644 --- a/doc/administration/package_information/supported_os.md +++ b/doc/administration/package_information/supported_os.md @@ -41,6 +41,7 @@ architecture. | Scientific Linux | GitLab CE / GitLab EE 8.14.0 | x86_64 | [Use CentOS Install Documentation](https://about.gitlab.com/install/#centos-7) | June 2024 | | | Ubuntu 20.04 | GitLab CE / GitLab EE 13.2.0 | amd64, arm64 | [Ubuntu Install Documentation](https://about.gitlab.com/install/#ubuntu) | April 2025 | | | Ubuntu 22.04 | GitLab CE / GitLab EE 15.5.0 | amd64, arm64 | [Ubuntu Install Documentation](https://about.gitlab.com/install/#ubuntu) | April 2027 | | +| Ubuntu 24.04 | GitLab CE / GitLab EE 17.1.0 | amd64, arm64 | [Ubuntu Install Documentation](https://about.gitlab.com/install/#ubuntu) | April 2029 | | | Amazon Linux 2 | GitLab CE / GitLab EE 14.9.0 | amd64, arm64 | [Amazon Linux 2 Install Documentation](https://about.gitlab.com/install/#amazonlinux-2) | June 2025 | | | Amazon Linux 2023 | GitLab CE / GitLab EE 16.3.0 | amd64, arm64 | [Amazon Linux 2023 Install Documentation](https://about.gitlab.com/install/#amazonlinux-2023) | 2028 | | | Raspberry Pi OS (Buster) (formerly known as Raspbian Buster) | GitLab CE 12.2.0 | armhf | [Raspberry Pi Install Documentation](https://about.gitlab.com/install/#raspberry-pi-os) | June 2024 | [Raspberry Pi Details](https://www.raspberrypi.com/news/new-old-functionality-with-raspberry-pi-os-legacy/) | diff --git a/doc/administration/postgresql/multiple_databases.md b/doc/administration/postgresql/multiple_databases.md index 55883ab36cd..06a239738d5 100644 --- a/doc/administration/postgresql/multiple_databases.md +++ b/doc/administration/postgresql/multiple_databases.md @@ -58,20 +58,20 @@ If something unexpected happens during the migration, it is safe to start over. - The database node that will store the `gitlabhq_production_ci` database needs enough space to store a copy of the existing database: we _duplicate_ `gitlabhq_production`. Run the following SQL query to find out how much space is needed. Add 25%, to ensure you will not run out of disk space. - ```shell - sudo gitlab-psql -c "SELECT pg_size_pretty( pg_database_size('gitlabhq_production') );" - ``` + ```shell + sudo gitlab-psql -c "SELECT pg_size_pretty( pg_database_size('gitlabhq_production') );" + ``` - During the process, a dump of the `gitlabhq_production` database needs to be temporarily stored on the filesystem of the node that will run the migration. Execute the following SQL statement to find out how much local disk space will be used. Add 25%, to ensure you will not run out of disk space. - ```shell - sudo gitlab-psql -c "select sum(pg_table_size(concat(table_schema,'.',table_name))) from information_schema.tables where table_catalog = 'gitlabhq_production' and table_type = 'BASE TABLE'" - ``` + ```shell + sudo gitlab-psql -c "select sum(pg_table_size(concat(table_schema,'.',table_name))) from information_schema.tables where table_catalog = 'gitlabhq_production' and table_type = 'BASE TABLE'" + ``` 1. Plan for downtime. The downtime is dependent on the size of the `gitlabhq_production` database. - - We dump `gitlabhq_production` and restore it into a new `gitlabhq_production_ci` database. Database sizes below 50 GB should be done within 30 minutes. Larger databases need more time. For example, a 100 GB database needs 1-2 hours to be copied to the new database. - - We advise to also plan some time for smaller tasks like modifying the configuration. + - We dump `gitlabhq_production` and restore it into a new `gitlabhq_production_ci` database. Database sizes below 50 GB should be done within 30 minutes. Larger databases need more time. For example, a 100 GB database needs 1-2 hours to be copied to the new database. + - We advise to also plan some time for smaller tasks like modifying the configuration. 1. Create the new `gitlabhq_production_ci` database: diff --git a/doc/ci/runners/runner_fleet_dashboard.md b/doc/ci/runners/runner_fleet_dashboard.md index c0688fbeb88..5d92913c2fe 100644 --- a/doc/ci/runners/runner_fleet_dashboard.md +++ b/doc/ci/runners/runner_fleet_dashboard.md @@ -6,7 +6,7 @@ info: >- this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Runner Fleet Dashboard +# Runner fleet dashboard DETAILS: **Tier:** Ultimate @@ -14,17 +14,17 @@ DETAILS: > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/424495) in GitLab 16.6 -GitLab administrators can use the Runner Fleet Dashboard to assess the health of your instance runners. -The Runner Fleet Dashboard shows: +GitLab administrators can use the runner fleet dashboard to assess the health of your instance runners. +The runner fleet dashboard shows: - Recent CI errors caused by runner infrastructure - Number of concurrent jobs executed on most busy runners - Compute minutes used by instance runners - Job queue times (available only with [ClickHouse](#enable-more-ci-analytics-features-with-clickhouse)) -![Runner Fleet Dashboard](img/runner_fleet_dashboard.png) +![Runner fleet dashboard](img/runner_fleet_dashboard.png) -## View the Runner Fleet Dashboard +## View the runner fleet dashboard Prerequisites: @@ -75,11 +75,12 @@ For more information, see [epic 11180](https://gitlab.com/groups/gitlab-org/-/ep To enable additional CI analytics features, [configure the ClickHouse integration](../../integration/clickhouse.md). -For a video walkthrough, see [Setting up Runner Fleet Dashboard with ClickHouse](https://www.youtube.com/watch?v=YpGV95Ctbpk). +For an overview, see [Setting up runner fleet dashboard with ClickHouse](https://www.youtube.com/watch?v=YpGV95Ctbpk). + ## Feedback -To help us improve the Runner Fleet Dashboard, you can provide feedback in +To help us improve the runner fleet dashboard, you can provide feedback in [issue 421737](https://gitlab.com/gitlab-org/gitlab/-/issues/421737). In particular: diff --git a/doc/ci/runners/runner_fleet_dashboard_groups.md b/doc/ci/runners/runner_fleet_dashboard_groups.md index 0421c105850..effe5ec9274 100644 --- a/doc/ci/runners/runner_fleet_dashboard_groups.md +++ b/doc/ci/runners/runner_fleet_dashboard_groups.md @@ -15,7 +15,7 @@ DETAILS: Users with at least the Maintainer role for a group can use the runner fleet dashboard to assess the health of group runners. -![Runner Fleet Dashboard for Groups](img/runner_fleet_dashboard_groups.png) +![Runner fleet dashboard for groups](img/runner_fleet_dashboard_groups.png) ## Dashboard metrics diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md index 89d6a480eee..5bc4b88cba1 100644 --- a/doc/development/ee_features.md +++ b/doc/development/ee_features.md @@ -218,9 +218,9 @@ To guard your licensed feature: - For a global (system-wide) feature: - ```ruby - License.feature_available?(:my_feature_name) # true if available in this instance - ``` + ```ruby + License.feature_available?(:my_feature_name) # true if available in this instance + ``` 1. Optional. If your global feature is also available to namespaces with a paid plan, combine two feature identifiers to allow both administrators and group users. For example: diff --git a/doc/development/stage_group_observability/gitlab_instrumentation_for_opentelemetry.md b/doc/development/stage_group_observability/gitlab_instrumentation_for_opentelemetry.md index 6149c641b2c..913d6d92e00 100644 --- a/doc/development/stage_group_observability/gitlab_instrumentation_for_opentelemetry.md +++ b/doc/development/stage_group_observability/gitlab_instrumentation_for_opentelemetry.md @@ -23,32 +23,32 @@ Once you have a project identified to use: 1. Note the ID of the top-level root group which contains the project. 1. When setting the environment variables for the following steps, add them to `env.runit` in the root of the `gitlab-development-kit` folder. 1. Follow instructions to [configure distributed tracing for a project](../../operations/tracing.md), with the following custom settings: - - For the `OTEL_EXPORTER_OTLP_TRACES_ENDPOINT` environment variable, use the following value: + - For the `OTEL_EXPORTER_OTLP_TRACES_ENDPOINT` environment variable, use the following value: - ```shell - export OTEL_EXPORTER_OTLP_TRACES_ENDPOINT="https:///v3///ingest/traces" - ``` + ```shell + export OTEL_EXPORTER_OTLP_TRACES_ENDPOINT="https:///v3///ingest/traces" + ``` 1. Follow instructions to [configure distributed metrics for a project](../../operations/metrics.md), with the following custom settings: - - For the `OTEL_EXPORTER_OTLP_METRICS_ENDPOINT` environment variable, use the following value: + - For the `OTEL_EXPORTER_OTLP_METRICS_ENDPOINT` environment variable, use the following value: - ```shell - export OTEL_EXPORTER_OTLP_METRICS_ENDPOINT="https:///v3///ingest/metrics" - ``` + ```shell + export OTEL_EXPORTER_OTLP_METRICS_ENDPOINT="https:///v3///ingest/metrics" + ``` 1. Follow instructions to [configure distributed logs for a project](../../operations/logs.md), with the following custom settings: - - For the `OTEL_EXPORTER_OTLP_LOGS_ENDPOINT` environment variable, use the following value: + - For the `OTEL_EXPORTER_OTLP_LOGS_ENDPOINT` environment variable, use the following value: - ```shell - export OTEL_EXPORTER_OTLP_LOGS_ENDPOINT="https:///v3///ingest/logs" - ``` + ```shell + export OTEL_EXPORTER_OTLP_LOGS_ENDPOINT="https:///v3///ingest/logs" + ``` 1. Also add the following to the `env.runit` file: - ```shell - # GitLab-specific flag to enable the Rails initializer to set up OpenTelemetry exporters - export GITLAB_ENABLE_OTEL_EXPORTERS=true - ``` + ```shell + # GitLab-specific flag to enable the Rails initializer to set up OpenTelemetry exporters + export GITLAB_ENABLE_OTEL_EXPORTERS=true + ``` 1. `gdk restart`. 1. Navigate to your project, and follow the instructions in the above docs to enable and view the tracing, metrics, or logs. diff --git a/doc/integration/google_cloud_iam.md b/doc/integration/google_cloud_iam.md index 0e23fa58137..c3a53c3b215 100644 --- a/doc/integration/google_cloud_iam.md +++ b/doc/integration/google_cloud_iam.md @@ -75,7 +75,7 @@ Prerequisites: ``` 1. Add an OIDC provider to the workload identity pool with the following - command. Replace these values: + command. Replace these values: - `` with the ID to use for the provider, which must be 4 to 32 lowercase letters, digits, or hyphens. To avoid @@ -132,10 +132,10 @@ After you create the workload identity pool and provider, to complete the setup 1. Select **Manual setup** 1. Complete the fields. - **[Project ID](https://cloud.google.com/resource-manager/docs/creating-managing-projects#identifying_projects)** - for the Google Cloud project in which you created the workload identity. - pool and provider. Example: `my-sample-project-191923`. + for the Google Cloud project in which you created the workload identity. + pool and provider. Example: `my-sample-project-191923`. - **[Project number](https://cloud.google.com/resource-manager/docs/creating-managing-projects#identifying_projects)** - for the same Google Cloud project. Example: `314053285323`. + for the same Google Cloud project. Example: `314053285323`. - **Pool ID** of the workload identity pool you created for this integration. - **Provider ID** of the workload identity provider you created for this integration. diff --git a/doc/operations/feature_flags.md b/doc/operations/feature_flags.md index 24992468bbb..aab09f0a1ef 100644 --- a/doc/operations/feature_flags.md +++ b/doc/operations/feature_flags.md @@ -49,7 +49,7 @@ To create and enable a feature flag: or dashes (`-`), and does not end with a dash (`-`) or underscore (`_`). 1. Optional. Enter a description (255 characters maximum). 1. Add feature flag [**Strategies**](#feature-flag-strategies) to define how the flag should be applied. For each strategy, include the **Type** (defaults to [**All users**](#all-users)) - and **Environments** (defaults to all environments). + and **Environments** (defaults to all environments). 1. Select **Create feature flag**. To change these settings, select **Edit** (**{pencil}**) diff --git a/doc/subscriptions/subscription-add-ons.md b/doc/subscriptions/subscription-add-ons.md index 73230b17b02..cd163985761 100644 --- a/doc/subscriptions/subscription-add-ons.md +++ b/doc/subscriptions/subscription-add-ons.md @@ -72,10 +72,10 @@ Prerequisites: 1. On the left sidebar, at the bottom, select **Admin Area**. 1. Select **GitLab Duo Pro**. - If the **GitLab Duo Pro** menu item is not available, synchronize your subscription - after purchase: + after purchase: 1. On the left sidebar, select **Subscription**. 1. In **Subscription details**, to the right of **Last sync**, select - synchronize subscription (**{retry}**). + synchronize subscription (**{retry}**). 1. To the right of the user, turn on the toggle to assign GitLab Duo Pro. #### Configure network and proxy settings diff --git a/doc/topics/autodevops/multiple_clusters_auto_devops.md b/doc/topics/autodevops/multiple_clusters_auto_devops.md index c0c25b09e67..4ab9c1689ac 100644 --- a/doc/topics/autodevops/multiple_clusters_auto_devops.md +++ b/doc/topics/autodevops/multiple_clusters_auto_devops.md @@ -26,13 +26,13 @@ To deploy your environments to different Kubernetes clusters: 1. [Create Kubernetes clusters](../../user/infrastructure/clusters/connect/new_gke_cluster.md). 1. Associate the clusters to your project: - 1. [Install a GitLab agent on each cluster](../../user/clusters/agent/index.md). - 1. [Configure each agent to access your project](../../user/clusters/agent/install/index.md#configure-your-agent). + 1. [Install a GitLab agent on each cluster](../../user/clusters/agent/index.md). + 1. [Configure each agent to access your project](../../user/clusters/agent/install/index.md#configure-your-agent). 1. [Install NGINX Ingress Controller](cloud_deployments/auto_devops_with_gke.md#install-ingress) in each cluster. Save the IP address and Kubernetes namespace for the next step. 1. [Configure the Auto DevOps CI/CD Pipeline variables](cicd_variables.md#build-and-deployment-variables) - - Set up a `KUBE_CONTEXT` variable [for each environment](../../ci/environments/index.md#limit-the-environment-scope-of-a-cicd-variable). The value must point to the agent of the relevant cluster. - - Set up a `KUBE_INGRESS_BASE_DOMAIN`. You must [configure the base domain](requirements.md#auto-devops-base-domain) for each environment to point to the Ingress of the relevant cluster. - - Add a `KUBE_NAMESPACE` variable with a value of the Kubernetes namespace you want your deployments to target. You can scope the variable to multiple environments. + - Set up a `KUBE_CONTEXT` variable [for each environment](../../ci/environments/index.md#limit-the-environment-scope-of-a-cicd-variable). The value must point to the agent of the relevant cluster. + - Set up a `KUBE_INGRESS_BASE_DOMAIN`. You must [configure the base domain](requirements.md#auto-devops-base-domain) for each environment to point to the Ingress of the relevant cluster. + - Add a `KUBE_NAMESPACE` variable with a value of the Kubernetes namespace you want your deployments to target. You can scope the variable to multiple environments. For deprecated, [certificate-based clusters](../../user/infrastructure/clusters/index.md#certificate-based-kubernetes-integration-deprecated): diff --git a/doc/update/background_migrations_troubleshooting.md b/doc/update/background_migrations_troubleshooting.md index 19645bfb9e7..fcdf04e1e27 100644 --- a/doc/update/background_migrations_troubleshooting.md +++ b/doc/update/background_migrations_troubleshooting.md @@ -33,17 +33,17 @@ If you have, you can [manually finish the batched background migration](backgrou If you haven't, choose one of the following methods: 1. [Rollback and upgrade](#roll-back-and-follow-the-required-upgrade-path) through one of the required -versions before updating to 14.2+. + versions before updating to 14.2+. 1. [Roll forward](#roll-forward-and-finish-the-migrations-on-the-upgraded-version), staying on the current -version and manually ensuring that the batched migrations complete successfully. + version and manually ensuring that the batched migrations complete successfully. ### Roll back and follow the required upgrade path 1. [Rollback and restore the previously installed version](../administration/backup_restore/index.md) 1. Update to either 14.0.5 or 14.1 **before** updating to 14.2+ 1. [Check the status](background_migrations.md#check-the-status-of-batched-background-migrations) of the batched background migrations and -make sure they are all marked as finished before attempting to upgrade again. If any remain marked as active, -you can [manually finish them](background_migrations.md#finish-a-failed-migration-manually). + make sure they are all marked as finished before attempting to upgrade again. If any remain marked as active, + you can [manually finish them](background_migrations.md#finish-a-failed-migration-manually). ### Roll forward and finish the migrations on the upgraded version @@ -53,8 +53,8 @@ To run all the batched background migrations, it can take a significant amount o depending on the size of your GitLab installation. 1. [Check the status](background_migrations.md#check-the-status-of-batched-background-migrations) of the batched background migrations in the -database, and [manually run them](background_migrations.md#finish-a-failed-migration-manually) with the appropriate -arguments until the status query returns no rows. + database, and [manually run them](background_migrations.md#finish-a-failed-migration-manually) with the appropriate + arguments until the status query returns no rows. 1. When the status of all of all them is marked as complete, re-run migrations for your installation. 1. [Complete the database migrations](../administration/raketasks/maintenance.md#run-incomplete-database-migrations) from your GitLab upgrade: @@ -76,8 +76,8 @@ As the failing migrations are post-deployment migrations, you can remain on a ru version and wait for the batched background migrations to finish. 1. [Check the status](background_migrations.md#check-the-status-of-batched-background-migrations) of the batched background migration from -the error message, and make sure it is listed as finished. If it is still active, either wait until it is done, -or [manually finish it](background_migrations.md#finish-a-failed-migration-manually). + the error message, and make sure it is listed as finished. If it is still active, either wait until it is done, + or [manually finish it](background_migrations.md#finish-a-failed-migration-manually). 1. Re-run migrations for your installation, so the remaining post-deployment migrations finish. ## Background migrations remain in the Sidekiq queue diff --git a/doc/update/deprecations.md b/doc/update/deprecations.md index de6bcc0987c..01bc4a0ad70 100644 --- a/doc/update/deprecations.md +++ b/doc/update/deprecations.md @@ -1981,11 +1981,11 @@ This is part of our long-term strategy to deliver a faster, more consistent user In GitLab 17.0, we will: 1. Remove a set of language-specific analyzers from the [SAST CI/CD template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml) and replace their coverage with [GitLab-supported detection rules](https://docs.gitlab.com/ee/user/application_security/sast/rules.html) in the [Semgrep-based analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep). The following analyzers are now deprecated and will reach End of Support in GitLab 17.0: - 1. [Brakeman](https://gitlab.com/gitlab-org/security-products/analyzers/brakeman) (Ruby, Ruby on Rails) - 1. [Flawfinder](https://gitlab.com/gitlab-org/security-products/analyzers/flawfinder) (C, C++) - 1. [MobSF](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf) (Android, iOS) - 1. [NodeJS Scan](https://gitlab.com/gitlab-org/security-products/analyzers/nodejs-scan) (Node.js) - 1. [PHPCS Security Audit](https://gitlab.com/gitlab-org/security-products/analyzers/phpcs-security-audit) (PHP) + 1. [Brakeman](https://gitlab.com/gitlab-org/security-products/analyzers/brakeman) (Ruby, Ruby on Rails) + 1. [Flawfinder](https://gitlab.com/gitlab-org/security-products/analyzers/flawfinder) (C, C++) + 1. [MobSF](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf) (Android, iOS) + 1. [NodeJS Scan](https://gitlab.com/gitlab-org/security-products/analyzers/nodejs-scan) (Node.js) + 1. [PHPCS Security Audit](https://gitlab.com/gitlab-org/security-products/analyzers/phpcs-security-audit) (PHP) 1. Change the [SAST CI/CD template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml) to stop running the [SpotBugs-based analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs) for Kotlin and Scala code. These languages will instead be scanned using [GitLab-supported detection rules](https://docs.gitlab.com/ee/user/application_security/sast/rules.html) in the [Semgrep-based analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep). Effective immediately, the deprecated analyzers will receive only security updates; other routine improvements or updates are not guaranteed. diff --git a/doc/update/versions/gitlab_16_changes.md b/doc/update/versions/gitlab_16_changes.md index 0643af70c47..015d20b6fae 100644 --- a/doc/update/versions/gitlab_16_changes.md +++ b/doc/update/versions/gitlab_16_changes.md @@ -269,12 +269,12 @@ planned for release in 16.9.1. ### Geo installations - PostgreSQL version 14 is the default for fresh installations of GitLab 16.7 and later. Due to a known issue, existing Geo secondary -sites cannot be upgraded to PostgreSQL version 14. For more information, see [issue 7768](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7768#note_1652076255). -All Geo sites must run the same version of PostgreSQL. To add a new Geo secondary site on GitLab 16.7 to 16.8.1, -you must take one of the following actions based on your configuration: + sites cannot be upgraded to PostgreSQL version 14. For more information, see [issue 7768](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7768#note_1652076255). + All Geo sites must run the same version of PostgreSQL. To add a new Geo secondary site on GitLab 16.7 to 16.8.1, + you must take one of the following actions based on your configuration: - To add your first Geo secondary site: [Upgrade the Primary site to PostgreSQL 14](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server) - before you set up the new Geo secondary site. No special action is required if your primary site is already running PostgreSQL 14. + before you set up the new Geo secondary site. No special action is required if your primary site is already running PostgreSQL 14. - To add a new Geo secondary site to a deployment that already has one or more Geo secondaries: - If all existing sites are running PostgreSQL 13, install the new Geo secondary site with [pinned PostgreSQL version 13](https://docs.gitlab.com/omnibus/settings/database.html#pin-the-packaged-postgresql-version-fresh-installs-only). - If all existing sites are running PostgreSQL 14: No special action is required. @@ -357,9 +357,9 @@ Specific information applies to Linux package installations: ### Geo installations - PostgreSQL version 14 is the default for fresh installations of GitLab 16.7 and later. Due to a known issue, existing Geo secondary -sites cannot be upgraded to PostgreSQL version 14. For more information, see [issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7768#note_1652076255). -All Geo sites must run the same version of PostgreSQL. To add a new Geo secondary site based on GitLab 16.7 to 16.8.1, you must -take one of the following actions based on your configuration: + sites cannot be upgraded to PostgreSQL version 14. For more information, see [issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7768#note_1652076255). + All Geo sites must run the same version of PostgreSQL. To add a new Geo secondary site based on GitLab 16.7 to 16.8.1, you must + take one of the following actions based on your configuration: - You are adding your first Geo secondary site: [Upgrade the Primary site to PostgreSQL 14](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server) before setting up the new Geo secondary site. No special action is required if your primary site is already running PostgreSQL 14. - You are adding a new Geo secondary site to a deployment that already has one or more Geo secondaries: diff --git a/doc/update/zero_downtime.md b/doc/update/zero_downtime.md index 47833e32656..246134f98e6 100644 --- a/doc/update/zero_downtime.md +++ b/doc/update/zero_downtime.md @@ -53,7 +53,7 @@ In addition to the above, please be aware of the following considerations: - Some releases may include [background migrations](index.md#check-for-background-migrations-before-upgrading). These migrations are performed in the background by Sidekiq and are often used for migrating data. Background migrations are only added in the monthly releases. - Certain major or minor releases may require a set of background migrations to be finished. While this doesn't require downtime (if the above conditions are met), it's required that you [wait for background migrations to complete](index.md#check-for-background-migrations-before-upgrading) between each major or minor release upgrade. - The time necessary to complete these migrations can be reduced by increasing the number of Sidekiq workers that can process jobs in the -`background_migration` queue. To see the size of this queue, [check for background migrations before upgrading](index.md#check-for-background-migrations-before-upgrading). + `background_migration` queue. To see the size of this queue, [check for background migrations before upgrading](index.md#check-for-background-migrations-before-upgrading). - [PostgreSQL major version upgrades](../administration/postgresql/replication_and_failover.md#near-zero-downtime-upgrade-of-postgresql-in-a-patroni-cluster) are a separate process and not covered by zero-downtime upgrades (smaller upgrades are covered). - Zero-downtime upgrades are supported for any GitLab components you've deployed with the GitLab Linux package. If you've deployed select components via a supported third party service, such as PostgreSQL in AWS RDS or Redis in GCP Memorystore, upgrades for those services will need to be performed separately as per their standard processes. - As a general guideline, the larger amount of data you have, the more time it will take for the upgrade to complete. In testing, any database smaller than 10 GB shouldn't generally take longer than an hour, but your mileage may vary. @@ -216,81 +216,81 @@ In addition to the above, Rails is where the main database migrations need to be 1. On the **Rails deploy node**: - 1. Drain the node of traffic gracefully. This can be done in various ways, but one approach is via - NGINX by sending it a `QUIT` signal and then stopping the service. As an example this could be - done via the following shell script: + 1. Drain the node of traffic gracefully. This can be done in various ways, but one approach is via + NGINX by sending it a `QUIT` signal and then stopping the service. As an example this could be + done via the following shell script: - ```shell - # Send QUIT to NGINX master process to drain and exit - NGINX_PID=$(cat /var/opt/gitlab/nginx/nginx.pid) - kill -QUIT $NGINX_PID + ```shell + # Send QUIT to NGINX master process to drain and exit + NGINX_PID=$(cat /var/opt/gitlab/nginx/nginx.pid) + kill -QUIT $NGINX_PID - # Wait for drain to complete - while kill -0 $NGINX_PID 2>/dev/null; do sleep 1; done + # Wait for drain to complete + while kill -0 $NGINX_PID 2>/dev/null; do sleep 1; done - # Stop NGINX service to prevent automatic restarts - gitlab-ctl stop nginx - ``` + # Stop NGINX service to prevent automatic restarts + gitlab-ctl stop nginx + ``` - 1. Create an empty file at `/etc/gitlab/skip-auto-reconfigure`. This prevents upgrades from running `gitlab-ctl reconfigure`, which by default automatically stops GitLab, runs all database migrations, and restarts GitLab: + 1. Create an empty file at `/etc/gitlab/skip-auto-reconfigure`. This prevents upgrades from running `gitlab-ctl reconfigure`, which by default automatically stops GitLab, runs all database migrations, and restarts GitLab: - ```shell - sudo touch /etc/gitlab/skip-auto-reconfigure - ``` + ```shell + sudo touch /etc/gitlab/skip-auto-reconfigure + ``` - 1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories). + 1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories). - 1. Configure regular migrations to by setting `gitlab_rails['auto_migrate'] = true` in the - `/etc/gitlab/gitlab.rb` configuration file. - - If the deploy node is currently going through PgBouncer to reach the database then - you must [bypass it](../administration/postgresql/pgbouncer.md#procedure-for-bypassing-pgbouncer) - and connect directly to the database leader before running migrations. - - To find the database leader you can run the following command on any database node - `sudo gitlab-ctl patroni members`. + 1. Configure regular migrations to by setting `gitlab_rails['auto_migrate'] = true` in the + `/etc/gitlab/gitlab.rb` configuration file. + - If the deploy node is currently going through PgBouncer to reach the database then + you must [bypass it](../administration/postgresql/pgbouncer.md#procedure-for-bypassing-pgbouncer) + and connect directly to the database leader before running migrations. + - To find the database leader you can run the following command on any database node - `sudo gitlab-ctl patroni members`. - 1. Run the regular migrations and get the latest code in place: + 1. Run the regular migrations and get the latest code in place: - ```shell - sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-ctl reconfigure - ``` + ```shell + sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-ctl reconfigure + ``` - 1. Leave this node as-is for now as you'll come back to run post-deployment migrations - later. + 1. Leave this node as-is for now as you'll come back to run post-deployment migrations + later. 1. On every **other Rails node** sequentially: - 1. Drain the node of traffic gracefully. This can be done in various ways, but one approach is via - NGINX by sending it a `QUIT` signal and then stopping the service. As an example this could be - done via the following shell script: + 1. Drain the node of traffic gracefully. This can be done in various ways, but one approach is via + NGINX by sending it a `QUIT` signal and then stopping the service. As an example this could be + done via the following shell script: - ```shell - # Send QUIT to NGINX master process to drain and exit - NGINX_PID=$(cat /var/opt/gitlab/nginx/nginx.pid) - kill -QUIT $NGINX_PID + ```shell + # Send QUIT to NGINX master process to drain and exit + NGINX_PID=$(cat /var/opt/gitlab/nginx/nginx.pid) + kill -QUIT $NGINX_PID - # Wait for drain to complete - while kill -0 $NGINX_PID 2>/dev/null; do sleep 1; done + # Wait for drain to complete + while kill -0 $NGINX_PID 2>/dev/null; do sleep 1; done - # Stop NGINX service to prevent automatic restarts - gitlab-ctl stop nginx - ``` + # Stop NGINX service to prevent automatic restarts + gitlab-ctl stop nginx + ``` - 1. Create an empty file at `/etc/gitlab/skip-auto-reconfigure`. This prevents upgrades from running `gitlab-ctl reconfigure`, which by default automatically stops GitLab, runs all database migrations, and restarts GitLab: + 1. Create an empty file at `/etc/gitlab/skip-auto-reconfigure`. This prevents upgrades from running `gitlab-ctl reconfigure`, which by default automatically stops GitLab, runs all database migrations, and restarts GitLab: - ```shell - sudo touch /etc/gitlab/skip-auto-reconfigure - ``` + ```shell + sudo touch /etc/gitlab/skip-auto-reconfigure + ``` - 1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories). + 1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories). - 1. Ensure that `gitlab_rails['auto_migrate'] = false` is set in `/etc/gitlab/gitlab.rb` to prevent - `reconfigure` from automatically running database migrations. + 1. Ensure that `gitlab_rails['auto_migrate'] = false` is set in `/etc/gitlab/gitlab.rb` to prevent + `reconfigure` from automatically running database migrations. - 1. Run the `reconfigure` command to get the latest code in place as well as restart: + 1. Run the `reconfigure` command to get the latest code in place as well as restart: - ```shell - sudo gitlab-ctl reconfigure - sudo gitlab-ctl restart - ``` + ```shell + sudo gitlab-ctl reconfigure + sudo gitlab-ctl restart + ``` 1. On the **Rails deploy node** run the post-deployment migrations: @@ -298,7 +298,7 @@ In addition to the above, Rails is where the main database migrations need to be is currently going through PgBouncer to reach the database then you must [bypass it](../administration/postgresql/pgbouncer.md#procedure-for-bypassing-pgbouncer) and connect directly to the database leader before running migrations. - - To find the database leader you can run the following command on any database node - `sudo gitlab-ctl patroni members`. + - To find the database leader you can run the following command on any database node - `sudo gitlab-ctl patroni members`. 1. Run the post-deployment migrations: @@ -307,15 +307,15 @@ In addition to the above, Rails is where the main database migrations need to be ``` 1. Return the config back to normal by setting `gitlab_rails['auto_migrate'] = false` in the - `/etc/gitlab/gitlab.rb` configuration file. - - If PgBouncer is being used make sure to set the database config to once again point towards it + `/etc/gitlab/gitlab.rb` configuration file. + - If PgBouncer is being used make sure to set the database config to once again point towards it 1. Run through reconfigure once again to reapply the normal config as well as restart: - ```shell - sudo gitlab-ctl reconfigure - sudo gitlab-ctl restart - ``` + ```shell + sudo gitlab-ctl reconfigure + sudo gitlab-ctl restart + ``` ### Sidekiq @@ -375,95 +375,95 @@ below: 1. On the **Rails deploy node**: - 1. Drain the node of traffic gracefully. This can be done in various ways, but one approach is via - NGINX by sending it a `QUIT` signal and then stopping the service. As an example this could be - done via the following shell script: + 1. Drain the node of traffic gracefully. This can be done in various ways, but one approach is via + NGINX by sending it a `QUIT` signal and then stopping the service. As an example this could be + done via the following shell script: - ```shell - # Send QUIT to NGINX master process to drain and exit - NGINX_PID=$(cat /var/opt/gitlab/nginx/nginx.pid) - kill -QUIT $NGINX_PID + ```shell + # Send QUIT to NGINX master process to drain and exit + NGINX_PID=$(cat /var/opt/gitlab/nginx/nginx.pid) + kill -QUIT $NGINX_PID - # Wait for drain to complete - while kill -0 $NGINX_PID 2>/dev/null; do sleep 1; done + # Wait for drain to complete + while kill -0 $NGINX_PID 2>/dev/null; do sleep 1; done - # Stop NGINX service to prevent automatic restarts - gitlab-ctl stop nginx - ``` + # Stop NGINX service to prevent automatic restarts + gitlab-ctl stop nginx + ``` - 1. Stop the Geo Logcursor process to ensure it fails over to another node: + 1. Stop the Geo Logcursor process to ensure it fails over to another node: - ```shell - gitlab-ctl stop geo-logcursor - ``` + ```shell + gitlab-ctl stop geo-logcursor + ``` - 1. Create an empty file at `/etc/gitlab/skip-auto-reconfigure`. This prevents upgrades from running `gitlab-ctl reconfigure`, which by default automatically stops GitLab, runs all database migrations, and restarts GitLab: + 1. Create an empty file at `/etc/gitlab/skip-auto-reconfigure`. This prevents upgrades from running `gitlab-ctl reconfigure`, which by default automatically stops GitLab, runs all database migrations, and restarts GitLab: - ```shell - sudo touch /etc/gitlab/skip-auto-reconfigure - ``` + ```shell + sudo touch /etc/gitlab/skip-auto-reconfigure + ``` - 1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories). + 1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories). - 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the primary site Rails node to the secondary site Rails node if they're different. The file must be the same on all of a site's nodes. + 1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the primary site Rails node to the secondary site Rails node if they're different. The file must be the same on all of a site's nodes. - 1. Ensure no migrations are configured to be run automatically by setting `gitlab_rails['auto_migrate'] = false` and `geo_secondary['auto_migrate'] = false` in the - `/etc/gitlab/gitlab.rb` configuration file. + 1. Ensure no migrations are configured to be run automatically by setting `gitlab_rails['auto_migrate'] = false` and `geo_secondary['auto_migrate'] = false` in the + `/etc/gitlab/gitlab.rb` configuration file. - 1. Run the `reconfigure` command to get the latest code in place as well as restart: + 1. Run the `reconfigure` command to get the latest code in place as well as restart: - ```shell - sudo gitlab-ctl reconfigure - sudo gitlab-ctl restart - ``` + ```shell + sudo gitlab-ctl reconfigure + sudo gitlab-ctl restart + ``` - 1. Run the regular Geo Tracking migrations and get the latest code in place: + 1. Run the regular Geo Tracking migrations and get the latest code in place: - ```shell - sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-rake db:migrate:geo - ``` + ```shell + sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-rake db:migrate:geo + ``` 1. On every **other Rails node** sequentially: - 1. Drain the node of traffic gracefully. This can be done in various ways, but one approach is via - NGINX by sending it a `QUIT` signal and then stopping the service. As an example this could be - done via the following shell script: + 1. Drain the node of traffic gracefully. This can be done in various ways, but one approach is via + NGINX by sending it a `QUIT` signal and then stopping the service. As an example this could be + done via the following shell script: - ```shell - # Send QUIT to NGINX master process to drain and exit - NGINX_PID=$(cat /var/opt/gitlab/nginx/nginx.pid) - kill -QUIT $NGINX_PID + ```shell + # Send QUIT to NGINX master process to drain and exit + NGINX_PID=$(cat /var/opt/gitlab/nginx/nginx.pid) + kill -QUIT $NGINX_PID - # Wait for drain to complete - while kill -0 $NGINX_PID 2>/dev/null; do sleep 1; done + # Wait for drain to complete + while kill -0 $NGINX_PID 2>/dev/null; do sleep 1; done - # Stop NGINX service to prevent automatic restarts - gitlab-ctl stop nginx - ``` + # Stop NGINX service to prevent automatic restarts + gitlab-ctl stop nginx + ``` - 1. Stop the Geo Logcursor process to ensure it fails over to another node: + 1. Stop the Geo Logcursor process to ensure it fails over to another node: - ```shell - gitlab-ctl stop geo-logcursor - ``` + ```shell + gitlab-ctl stop geo-logcursor + ``` - 1. Create an empty file at `/etc/gitlab/skip-auto-reconfigure`. This prevents upgrades from running `gitlab-ctl reconfigure`, which by default automatically stops GitLab, runs all database migrations, and restarts GitLab: + 1. Create an empty file at `/etc/gitlab/skip-auto-reconfigure`. This prevents upgrades from running `gitlab-ctl reconfigure`, which by default automatically stops GitLab, runs all database migrations, and restarts GitLab: - ```shell - sudo touch /etc/gitlab/skip-auto-reconfigure - ``` + ```shell + sudo touch /etc/gitlab/skip-auto-reconfigure + ``` - 1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories). + 1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories). - 1. Ensure no migrations are configured to be run automatically by setting `gitlab_rails['auto_migrate'] = false` and `geo_secondary['auto_migrate'] = false` in the - `/etc/gitlab/gitlab.rb` configuration file. + 1. Ensure no migrations are configured to be run automatically by setting `gitlab_rails['auto_migrate'] = false` and `geo_secondary['auto_migrate'] = false` in the + `/etc/gitlab/gitlab.rb` configuration file. - 1. Run the `reconfigure` command to get the latest code in place as well as restart: + 1. Run the `reconfigure` command to get the latest code in place as well as restart: - ```shell - sudo gitlab-ctl reconfigure - sudo gitlab-ctl restart - ``` + ```shell + sudo gitlab-ctl reconfigure + sudo gitlab-ctl restart + ``` #### Sidekiq @@ -481,7 +481,7 @@ Finally, head back to the primary site and finish the upgrade by running the pos is currently going through PgBouncer to reach the database then you must [bypass it](../administration/postgresql/pgbouncer.md#procedure-for-bypassing-pgbouncer) and connect directly to the database leader before running migrations. - - To find the database leader you can run the following command on any database node - `sudo gitlab-ctl patroni members`. + - To find the database leader you can run the following command on any database node - `sudo gitlab-ctl patroni members`. 1. Run the post-deployment migrations: @@ -496,15 +496,15 @@ Finally, head back to the primary site and finish the upgrade by running the pos ``` 1. Return the config back to normal by setting `gitlab_rails['auto_migrate'] = false` in the - `/etc/gitlab/gitlab.rb` configuration file. - - If PgBouncer is being used make sure to set the database config to once again point towards it + `/etc/gitlab/gitlab.rb` configuration file. + - If PgBouncer is being used make sure to set the database config to once again point towards it 1. Run through reconfigure once again to reapply the normal config as well as restart: - ```shell - sudo gitlab-ctl reconfigure - sudo gitlab-ctl restart - ``` + ```shell + sudo gitlab-ctl reconfigure + sudo gitlab-ctl restart + ``` 1. On the Secondary site's **Rails deploy node** run the post-deployment Geo Tracking migrations: diff --git a/doc/user/application_security/container_scanning/index.md b/doc/user/application_security/container_scanning/index.md index 1672cebe626..2b2f52011b8 100644 --- a/doc/user/application_security/container_scanning/index.md +++ b/doc/user/application_security/container_scanning/index.md @@ -823,6 +823,16 @@ To resolve this, instead of binding the `/tmp` folder, bind specific files or fo This error means a timeout occurred. To resolve it, add the `TRIVY_TIMEOUT` environment variable to the `container_scanning` job with a sufficiently long duration. +### Max allowed age is 5 days error + +When you try to use the Grype scanner, you might encounter the following error: + +```shell +1 error occurred: db could not be loaded: the vulnerability database was built 1 week ago (max allowed age is 5 days) +``` + +To resolve this issue, in the Container_Scanning job, set the variable `GRYPE_DB_VALIDATE_AGE` to `false`. + ## Changes Changes to the container scanning analyzer can be found in the project's diff --git a/doc/user/packages/composer_repository/index.md b/doc/user/packages/composer_repository/index.md index 981fbd14e54..e67f67ce27d 100644 --- a/doc/user/packages/composer_repository/index.md +++ b/doc/user/packages/composer_repository/index.md @@ -141,15 +141,15 @@ To install a package: - Connect to the package registry for your group: - ```shell - composer config repositories. composer https://gitlab.example.com/api/v4/group//-/packages/composer/packages.json - ``` + ```shell + composer config repositories. composer https://gitlab.example.com/api/v4/group//-/packages/composer/packages.json + ``` - Set the required package version: - ```shell - composer require : - ``` + ```shell + composer require : + ``` Result in the `composer.json` file: diff --git a/doc/user/project/issues/csv_export.md b/doc/user/project/issues/csv_export.md index fb830aa551f..18adad6bccb 100644 --- a/doc/user/project/issues/csv_export.md +++ b/doc/user/project/issues/csv_export.md @@ -80,6 +80,7 @@ The following columns are included in the CSV file. | Due Date | Formatted as `YYYY-MM-DD` | | Created At (UTC) | Formatted as `YYYY-MM-DD HH:MM:SS` | | Updated At (UTC) | Formatted as `YYYY-MM-DD HH:MM:SS` | +| Closed At (UTC) | Formatted as `YYYY-MM-DD HH:MM:SS` | | Milestone | Title of the issue milestone | | Weight | Issue weight | | Labels | Labels, separated by commas | diff --git a/locale/gitlab.pot b/locale/gitlab.pot index 3f724284a87..e5b01608180 100644 --- a/locale/gitlab.pot +++ b/locale/gitlab.pot @@ -9756,15 +9756,15 @@ msgstr "" msgid "BulkImport|Import failed: Destination cannot be a subgroup of the source group. Change the destination and try again." msgstr "" +msgid "BulkImport|Import from %{hostname} completed" +msgstr "" + msgid "BulkImport|Import groups by direct transfer" msgstr "" msgid "BulkImport|Import is finished. Pick another name for re-import" msgstr "" -msgid "BulkImport|Import of %{source_group} from %{hostname}" -msgstr "" - msgid "BulkImport|Import with projects" msgstr "" @@ -9867,7 +9867,7 @@ msgstr "" msgid "BulkImport|Template / File-based import / Direct transfer" msgstr "" -msgid "BulkImport|The import of %{strong_open}%{source_group}%{strong_close} from %{strong_open}%{hostname}%{strong_close} to %{strong_color_open}%{destination_group}%{strong_color_close} is complete. You can view the results of the import." +msgid "BulkImport|The import you started on %{start_date} from %{strong_open}%{hostname}%{strong_close} has completed. You can now review your import results." msgstr "" msgid "BulkImport|This %{importable} was imported from another instance." @@ -17586,8 +17586,10 @@ msgstr[1] "" msgid "Dependencies|%{locationCount} locations" msgstr "" -msgid "Dependencies|%{projectCount} projects" -msgstr "" +msgid "Dependencies|%{projectCount} project" +msgid_plural "Dependencies|%{projectCount} projects" +msgstr[0] "" +msgstr[1] "" msgid "Dependencies|%{remainingLicensesCount} more" msgstr "" @@ -33627,6 +33629,9 @@ msgstr[1] "" msgid "Mlmodelregistry|Provide the max allowed file size" msgstr "" +msgid "Mlmodelregistry|Subfolder cannot contain spaces" +msgstr "" + msgid "Mock an external CI integration." msgstr "" @@ -47459,6 +47464,9 @@ msgstr "" msgid "SecurityOrchestration|At least one framework label should be selected" msgstr "" +msgid "SecurityOrchestration|Automate vulnerability management workflows." +msgstr "" + msgid "SecurityOrchestration|Automatically selected runners" msgstr "" @@ -47630,6 +47638,9 @@ msgstr "" msgid "SecurityOrchestration|If any scanner finds a newly detected critical vulnerability in an open merge request targeting the main branch, then require two approvals from any two members of the application security team are required." msgstr "" +msgid "SecurityOrchestration|If any scanner finds a vulnerability that was previously detected but no longer found in a subsequent scan, then automatically set the status to Resolved." +msgstr "" + msgid "SecurityOrchestration|Individual users" msgstr "" @@ -48031,6 +48042,12 @@ msgstr "" msgid "SecurityOrchestration|Vulnerability age requires previously existing vulnerability states (detected, confirmed, resolved, or dismissed)" msgstr "" +msgid "SecurityOrchestration|Vulnerability management" +msgstr "" + +msgid "SecurityOrchestration|Vulnerability management policy" +msgstr "" + msgid "SecurityOrchestration|What does an example message look like?" msgstr "" @@ -50588,6 +50605,9 @@ msgstr "" msgid "Sorry, no projects matched your search" msgstr "" +msgid "Sorry, this page doesn't exist" +msgstr "" + msgid "Sorry, you have exceeded the maximum browsable page number. Please use the API to explore further." msgstr "" @@ -59604,6 +59624,9 @@ msgstr "" msgid "Wiki|There are no pages in this wiki yet" msgstr "" +msgid "Wiki|Use the sidebar to find a different page." +msgstr "" + msgid "Wiki|View all pages" msgstr "" diff --git a/spec/frontend/ml/model_registry/services/upload_model_spec.js b/spec/frontend/ml/model_registry/services/upload_model_spec.js index f8388c0d2da..149e9d2d615 100644 --- a/spec/frontend/ml/model_registry/services/upload_model_spec.js +++ b/spec/frontend/ml/model_registry/services/upload_model_spec.js @@ -43,6 +43,14 @@ describe('uploadModel', () => { }); }); + it('should not upload when the subfolder contains spaces', async () => { + const subfolder = 'sub folder'; + + await expect(uploadModel({ importPath, file, subfolder, maxAllowedFileSize })).rejects.toThrow( + new Error('Subfolder cannot contain spaces'), + ); + }); + it('should not make a request if no file is provided', async () => { await uploadModel({ importPath }); diff --git a/spec/mailers/emails/imports_spec.rb b/spec/mailers/emails/imports_spec.rb index 770cbbc21bc..4469b3339ac 100644 --- a/spec/mailers/emails/imports_spec.rb +++ b/spec/mailers/emails/imports_spec.rb @@ -30,22 +30,20 @@ RSpec.describe Emails::Imports, feature_category: :importers do describe '#bulk_import_complete' do let(:bulk_import) { build_stubbed(:bulk_import, :finished, :with_configuration) } - let(:bulk_import_entity) { build_stubbed(:bulk_import_entity, :group_entity) } subject { Notify.bulk_import_complete('user_id', 'bulk_import_id') } before do allow(User).to receive(:find).and_return(user) allow(BulkImport).to receive(:find).and_return(bulk_import) - allow(bulk_import).to receive(:parent_group_entity).and_return(bulk_import_entity) end it 'sends complete email' do - is_expected.to have_subject("Import of #{bulk_import_entity.source_full_path} from " \ - "#{bulk_import.configuration.url}") + is_expected.to have_subject("Import from #{bulk_import.configuration.url} completed") is_expected.to have_content('Import completed') - is_expected.to have_content("The import of #{bulk_import_entity.source_full_path} from " \ - "#{bulk_import.configuration.url} to #{bulk_import_entity.full_path_with_fallback} is complete.") + is_expected.to have_content("The import you started on " \ + "#{I18n.l(bulk_import.created_at.to_date, format: :long)} " \ + "from #{bulk_import.configuration.url} has completed. You can now review your import results.") is_expected.to have_body_text(history_import_bulk_import_url(bulk_import.id)) end end diff --git a/spec/mailers/previews_spec.rb b/spec/mailers/previews_spec.rb index b1eef1205e2..1957d13f5eb 100644 --- a/spec/mailers/previews_spec.rb +++ b/spec/mailers/previews_spec.rb @@ -16,7 +16,6 @@ RSpec.describe 'Mailer previews', feature_category: :shared do let_it_be(:review) { create(:review, project: project, merge_request: merge_request, author: user) } let_it_be(:key) { create(:key, user: user) } let_it_be(:bulk_import) { create(:bulk_import, :finished, :with_configuration) } - let_it_be(:bulk_import_entity) { create(:bulk_import_entity, :group_entity, bulk_import: bulk_import) } Gitlab.ee do let_it_be(:epic) { create(:epic, group: group) } diff --git a/spec/policies/board_policy_spec.rb b/spec/policies/board_policy_spec.rb index 6940e75ec37..3786fb22266 100644 --- a/spec/policies/board_policy_spec.rb +++ b/spec/policies/board_policy_spec.rb @@ -58,11 +58,29 @@ RSpec.describe BoardPolicy do end context 'create_non_backlog_issues' do + shared_examples 'with admin' do + let!(:current_user) { create(:user, :admin) } + + context 'when admin mode enabled', :enable_admin_mode do + it 'allows to add non backlog issues from issue board' do + expect_allowed(:create_non_backlog_issues) + end + end + + context 'when admin mode disabled' do + it 'does not allow to add non backlog issues from issue board' do + expect_disallowed(:create_non_backlog_issues) + end + end + end + context 'for project boards' do let!(:current_user) { create(:user) } subject { described_class.new(current_user, project_board) } + it_behaves_like 'with admin' + context 'when user can admin project issues' do it 'allows to add non backlog issues from issue board' do project.add_reporter(current_user) @@ -88,9 +106,7 @@ RSpec.describe BoardPolicy do subject { described_class.new(current_user, group_board) } - before do - project_1.add_guest(current_user) - end + it_behaves_like 'with admin' context 'when user is at least reporter in one of the child projects' do it 'allows to add non backlog issues from issue board' do diff --git a/spec/support/shared_examples/controllers/wiki_actions_shared_examples.rb b/spec/support/shared_examples/controllers/wiki_actions_shared_examples.rb index 83816790789..5c492da4bdc 100644 --- a/spec/support/shared_examples/controllers/wiki_actions_shared_examples.rb +++ b/spec/support/shared_examples/controllers/wiki_actions_shared_examples.rb @@ -255,8 +255,8 @@ RSpec.shared_examples 'wiki controller actions' do it 'shows the empty state' do request - expect(response).to have_gitlab_http_status(:ok) - expect(response).to render_template('shared/wikis/empty') + expect(response).to have_gitlab_http_status(:not_found) + expect(response).to render_template('shared/wikis/404') end end end