Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
4a0777f245
commit
3363204c90
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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'));
|
||||
}
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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(
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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) %>
|
||||
|
|
|
|||
|
|
@ -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'
|
||||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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 | <https://scientificlinux.org/downloads/sl-versions/sl7/> |
|
||||
| Ubuntu 20.04 | GitLab CE / GitLab EE 13.2.0 | amd64, arm64 | [Ubuntu Install Documentation](https://about.gitlab.com/install/#ubuntu) | April 2025 | <https://wiki.ubuntu.com/Releases> |
|
||||
| Ubuntu 22.04 | GitLab CE / GitLab EE 15.5.0 | amd64, arm64 | [Ubuntu Install Documentation](https://about.gitlab.com/install/#ubuntu) | April 2027 | <https://wiki.ubuntu.com/Releases> |
|
||||
| Ubuntu 24.04 | GitLab CE / GitLab EE 17.1.0 | amd64, arm64 | [Ubuntu Install Documentation](https://about.gitlab.com/install/#ubuntu) | April 2029 | <https://wiki.ubuntu.com/Releases> |
|
||||
| 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 | <https://aws.amazon.com/amazon-linux-2/faqs/> |
|
||||
| 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 | <https://docs.aws.amazon.com/linux/al2023/ug/release-cadence.html> |
|
||||
| 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/) |
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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))
|
||||
|
||||
|
||||
|
||||
|
||||
## 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).
|
||||
|
||||
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
|
||||
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).
|
||||
<!-- Video published on 2023-12-19 -->
|
||||
|
||||
## 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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
||||
|
||||
|
||||
## Dashboard metrics
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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://<gitlab-host>/v3/<gitlab-top-level-group-id>/<gitlab-project-id>/ingest/traces"
|
||||
```
|
||||
```shell
|
||||
export OTEL_EXPORTER_OTLP_TRACES_ENDPOINT="https://<gitlab-host>/v3/<gitlab-top-level-group-id>/<gitlab-project-id>/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://<gitlab-host>/v3/<gitlab-top-level-group-id>/<gitlab-project-id>/ingest/metrics"
|
||||
```
|
||||
```shell
|
||||
export OTEL_EXPORTER_OTLP_METRICS_ENDPOINT="https://<gitlab-host>/v3/<gitlab-top-level-group-id>/<gitlab-project-id>/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://<gitlab-host>/v3/<gitlab-top-level-group-id>/<gitlab-project-id>/ingest/logs"
|
||||
```
|
||||
```shell
|
||||
export OTEL_EXPORTER_OTLP_LOGS_ENDPOINT="https://<gitlab-host>/v3/<gitlab-top-level-group-id>/<gitlab-project-id>/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.
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
- `<your_identity_provider_id>` 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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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}**)
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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):
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -141,15 +141,15 @@ To install a package:
|
|||
|
||||
- Connect to the package registry for your group:
|
||||
|
||||
```shell
|
||||
composer config repositories.<group_id> composer https://gitlab.example.com/api/v4/group/<group_id>/-/packages/composer/packages.json
|
||||
```
|
||||
```shell
|
||||
composer config repositories.<group_id> composer https://gitlab.example.com/api/v4/group/<group_id>/-/packages/composer/packages.json
|
||||
```
|
||||
|
||||
- Set the required package version:
|
||||
|
||||
```shell
|
||||
composer require <package_name>:<version>
|
||||
```
|
||||
```shell
|
||||
composer require <package_name>:<version>
|
||||
```
|
||||
|
||||
Result in the `composer.json` file:
|
||||
|
||||
|
|
|
|||
|
|
@ -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 |
|
||||
|
|
|
|||
|
|
@ -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 ""
|
||||
|
||||
|
|
|
|||
|
|
@ -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 });
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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) }
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue