root
/
gitlab-ce
mirror of https://gitlab.com/free-releases/gitlab-ce.git
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2024-10-30 18:31:06 +00:00
parent b9b0853302
commit feebcf1ac5
44 changed files with 257 additions and 351 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
.rubocop_todo/lint/redundant_cop_disable_directive.yml
View File

@ -150,13 +150,6 @@ Lint/RedundantCopDisableDirective:
- 'qa/qa/resource/user_runners.rb'
- 'qa/qa/service/docker_run/gitlab_runner.rb'
- 'qa/qa/vendor/one_password/cli.rb'
- 'scripts/failed_tests.rb'
- 'scripts/feature_flags/used-feature-flags'
- 'scripts/generate_rspec_pipeline.rb'
- 'scripts/merge-auto-explain-logs'
- 'scripts/security-harness'
- 'scripts/setup/generate-as-if-foss-env.rb'
- 'scripts/verify-tff-mapping'
- 'spec/components/previews/pajamas/banner_component_preview.rb'
- 'spec/features/groups/participants_autocomplete_spec.rb'
- 'spec/features/merge_request/user_edits_mr_spec.rb'
@ -195,11 +188,3 @@ Lint/RedundantCopDisableDirective:
- 'spec/support/helpers/wait_for_requests.rb'
- 'spec/support/shared_examples/features/milestone_editing_shared_examples.rb'
- 'spec/support/shared_examples/models/concerns/protected_ref_access_shared_examples.rb'
- 'tooling/danger/ignored_model_columns.rb'
- 'tooling/danger/sidekiq_queues.rb'
- 'tooling/danger/stable_branch.rb'
- 'tooling/danger/suggestor.rb'
- 'tooling/lib/tooling/check_ruby_syntax.rb'
- 'tooling/lib/tooling/helm3_client.rb'
- 'tooling/lib/tooling/test_map_generator.rb'
- 'tooling/quality/test_level.rb'

6
app/assets/javascripts/ci/job_details/components/environments_block.vue
View File

@ -177,13 +177,13 @@ export default {
};
</script>
<template>
<div class="gl-mb-3 gl-mt-3" data-testid="jobs-environment-container">
<div class="gl-my-4" data-testid="jobs-environment-container">
<div
class="gl-border gl-rounded-base gl-px-5 gl-pb-4 gl-pt-3"
class="gl-border gl-flex gl-gap-3 gl-rounded-base gl-bg-subtle gl-p-4"
data-testid="jobs-environment-info"
>
<ci-icon :status="iconStatus" />
<p class="gl-mb-0 gl-inline-block">
<p class="gl-mb-0 gl-inline-block gl-self-center">
<gl-sprintf :message="environment">
<template #environmentLink>
<gl-link

24
app/assets/javascripts/ci/runner/group_new_runner/group_new_runner_app.vue
View File

@ -4,6 +4,7 @@ import { visitUrl } from '~/lib/utils/url_utility';
import { s__ } from '~/locale';
import { InternalEvents } from '~/tracking';
import glFeatureFlagsMixin from '~/vue_shared/mixins/gl_feature_flags_mixin';
import PageHeading from '~/vue_shared/components/page_heading.vue';
import RunnerCreateForm from '~/ci/runner/components/runner_create_form.vue';
import { DEFAULT_PLATFORM, GROUP_TYPE } from '../constants';
import { saveAlertToLocalStorage } from '../local_storage_alert/save_alert_to_local_storage';
@ -12,6 +13,7 @@ export default {
name: 'GroupNewRunnerApp',
components: {
RunnerCreateForm,
PageHeading,
},
mixins: [glFeatureFlagsMixin(), InternalEvents.mixin()],
props: {
@ -44,18 +46,16 @@ export default {
</script>
<template>
<div class="gl-mt-5">
<h1 class="gl-heading-1">{{ s__('Runners|New group runner') }}</h1>
<p>
{{
s__(
'Runners|Create a group runner to generate a command that registers the runner with all its configurations.',
)
}}
</p>
<hr aria-hidden="true" />
<div>
<page-heading :heading="s__('Runners|New group runner')">
<template #description>
{{
s__(
'Runners|Create a group runner to generate a command that registers the runner with all its configurations.',
)
}}
</template>
</page-heading>
<runner-create-form
:runner-type="$options.GROUP_TYPE"

24
app/assets/javascripts/ci/runner/project_new_runner/project_new_runner_app.vue
View File

@ -4,6 +4,7 @@ import { visitUrl } from '~/lib/utils/url_utility';
import { s__ } from '~/locale';
import { InternalEvents } from '~/tracking';
import glFeatureFlagsMixin from '~/vue_shared/mixins/gl_feature_flags_mixin';
import PageHeading from '~/vue_shared/components/page_heading.vue';
import RunnerCreateForm from '~/ci/runner/components/runner_create_form.vue';
import { DEFAULT_PLATFORM, GOOGLE_CLOUD_PLATFORM, PROJECT_TYPE } from '../constants';
import { saveAlertToLocalStorage } from '../local_storage_alert/save_alert_to_local_storage';
@ -12,6 +13,7 @@ export default {
name: 'ProjectNewRunnerApp',
components: {
RunnerCreateForm,
PageHeading,
},
mixins: [glFeatureFlagsMixin(), InternalEvents.mixin()],
props: {
@ -45,18 +47,16 @@ export default {
</script>
<template>
<div class="gl-mt-5">
<h1 class="gl-heading-1">{{ s__('Runners|New project runner') }}</h1>
<p>
{{
s__(
'Runners|Create a project runner to generate a command that registers the runner with all its configurations.',
)
}}
</p>
<hr aria-hidden="true" />
<div>
<page-heading :heading="s__('Runners|New project runner')">
<template #description>
{{
s__(
'Runners|Create a project runner to generate a command that registers the runner with all its configurations.',
)
}}
</template>
</page-heading>
<runner-create-form
:runner-type="$options.PROJECT_TYPE"

19
app/controllers/repositories/lfs_api_controller.rb
View File

@ -78,25 +78,6 @@ module Repositories
objects
end
def legacy_download_objects!
existing_oids = project.lfs_objects_oids(oids: objects_oids)
objects.each do |object|
if existing_oids.include?(object[:oid])
object[:actions] = proxy_download_actions(object)
object[:authenticated] = true if ::Users::Anonymous.can?(:download_code, project)
else
object[:error] = {
code: 404,
message: _("Object does not exist on the server or you don't have permissions to access it")
}
end
end
objects
end
def upload_objects!
existing_oids = project.lfs_objects_oids(oids: objects_oids)

77
danger/tailwindcss/Dangerfile
View File

@ -1,77 +0,0 @@
# frozen_string_literal: true
module Danger
class Tailwind
FRONTEND_INTERPOLATION_PATTERN = /gl-[0-9a-z-]+(\$\{|['"] ?\+)/
BACKEND_INTERPOLATION_PATTERN = /gl-[0-9a-z-]+(#\{|['"] ?\+)/
def initialize(helper, git)
@helper = helper
@git = git
end
def report_interpolated_utils
frontend_files_with_interpolated_utils = files_with_interpolated_utils(
frontend_tailwindy_files(@helper.all_changed_files), FRONTEND_INTERPOLATION_PATTERN)
backend_files_with_interpolated_utils = files_with_interpolated_utils(
backend_tailwindy_files(@helper.all_changed_files), BACKEND_INTERPOLATION_PATTERN)
return "" if frontend_files_with_interpolated_utils.empty? && backend_files_with_interpolated_utils.empty?
<<~MARKDOWN
### Interpolated utils
The following files might contain interpolated utils:
#{format_files_list(frontend_files_with_interpolated_utils + backend_files_with_interpolated_utils)}
If you are leveraging CSS utilities, make sure they are written in full and not built via string
interpolation as that would prevent Tailwind CSS from generating them.
MARKDOWN
end
private
def frontend_tailwindy_files(files)
files.select do |file|
file.end_with?('.vue', '.js')
end
end
def backend_tailwindy_files(files)
files.select do |file|
file.end_with?('.html.haml', '.rb')
end
end
def files_with_interpolated_utils(files, pattern)
files.select do |file|
diff = @git.diff_for_file(file)
# When a file is just moved around it appears in the changed files list
# but the diff is empty so we are skipping it.
next if diff.nil?
diff.patch.each_line.any? do |line|
line.start_with?('+') && line.match?(pattern)
end
end
end
def format_files_list(files)
files.map do |file|
"- `#{file}`"
end.join("\n")
end
end
end
danger_tailwind = Danger::Tailwind.new(helper, git)
report = danger_tailwind.report_interpolated_utils
unless report.empty?
markdown <<~MSG
## Tailwind CSS
#{report}
MSG
end

2
doc/administration/backup_restore/restore_gitlab.md
View File

@ -34,7 +34,7 @@ You can only restore a backup to **exactly the same version and type (CE or EE)*
of GitLab on which it was created. For example, CE 15.1.4.
If your backup is a different version than the current installation, you must
[downgrade](../../update/package/downgrade.md) or [upgrade](../../update/package/index.md#upgrade-to-a-specific-version-using-the-official-repositories) your GitLab installation
[downgrade](../../update/package/downgrade.md) or [upgrade](../../update/package/index.md#upgrade-to-a-specific-version) your GitLab installation
before restoring the backup.
### GitLab secrets must be restored

169
doc/administration/geo/replication/troubleshooting/synchronization_verification.md
View File

@ -66,115 +66,124 @@ console. The following sections describe how to use internal application
commands in the Rails console to cause replication or verification for
individual records synchronously or asynchronously.
In the context of GitLab Geo, a **registry record** refers to registry tables in
the Geo tracking database. Each record tracks a single replicable in the main
GitLab database, such as an LFS file, or a project Git repository. The Rails
models that correspond to Geo registry tables that can be queried are:
- `CiSecureFileRegistry`
- `ContainerRepositoryRegistry`
- `DependencyProxyBlobRegistry`
- `DependencyProxyManifestRegistry`
- `JobArtifactRegistry`
- `LfsObjectRegistry`
- `MergeRequestDiffRegistry`
- `PackageFileRegistry`
- `PagesDeploymentRegistry`
- `PipelineArtifactRegistry`
- `ProjectWikiRepositoryRegistry`
- `SnippetRepositoryRegistry`
- `TerraformStateVersionRegistry`
- `UploadRegistry`
You can use Rails to perform basic troubleshooting. Troubleshooting steps vary
depending on the object type.
#### For blob types
WARNING:
Commands that change data can cause damage if not run correctly or under the right conditions. Always run commands in a test environment first and have a backup instance ready to restore.
[Start a Rails console session](../../../../administration/operations/rails_console.md#starting-a-rails-console-session)
to enact the following, basic troubleshooting steps:
on a **secondary site**.
- **For Blob types** (using the `Packages::PackageFile` component as an example)
Using the `Packages::PackageFile` component as an example:
- Find registry records that failed to sync:
- Find registry records that failed to sync:
```ruby
Geo::PackageFileRegistry.failed
```
```ruby
Geo::PackageFileRegistry.failed
```
The term registry records, in this case, refers to registry tables in the
Geo tracking database. Each record, or row, tracks a single replicable in the
main GitLab database, such as an LFS file, or a project Git repository. Here
are some other Rails models that correspond to Geo registry tables that can
be queried like the above:
- Find registry records that are missing on the primary site:
```plaintext
CiSecureFileRegistry
ContainerRepositoryRegistry
DependencyProxyBlobRegistry
DependencyProxyManifestRegistry
JobArtifactRegistry
LfsObjectRegistry
MergeRequestDiffRegistry
PackageFileRegistry
PagesDeploymentRegistry
PipelineArtifactRegistry
ProjectWikiRepositoryRegistry
SnippetRepositoryRegistry
TerraformStateVersionRegistry
UploadRegistry
```
```ruby
Geo::PackageFileRegistry.where(last_sync_failure: 'The file is missing on the Geo primary site')
```
- Find registry records that are missing on the primary site:
- Resync a package file, synchronously, given an ID:
```ruby
Geo::PackageFileRegistry.where(last_sync_failure: 'The file is missing on the Geo primary site')
```
```ruby
model_record = Packages::PackageFile.find(<id>)
model_record.replicator.sync
```
- Resync a package file, synchronously, given an ID:
- Resync a package file, synchronously, given a registry ID:
```ruby
model_record = Packages::PackageFile.find(id)
model_record.replicator.sync
```
```ruby
registry = Geo::PackageFileRegistry.find(<registry_id>)
registry.replicator.sync
```
- Resync a package file, synchronously, given a registry ID:
- Resync a package file, asynchronously, given a registry ID.
Since GitLab 16.2, a component can be asynchronously replicated as follows:
```ruby
registry = Geo::PackageFileRegistry.find(registry_id)
registry.replicator.sync
```
```ruby
registry = Geo::PackageFileRegistry.find(<registry_id>)
registry.replicator.enqueue_sync
```
- Resync a package file, asynchronously, given a registry ID.
Since GitLab 16.2, a component can be asynchronously replicated as follows:
- Reverify a package file, asynchronously, given a registry ID.
Since GitLab 16.2, a component can be asynchronously reverified as follows:
```ruby
registry = Geo::PackageFileRegistry.find(registry_id)
registry.replicator.enqueue_sync
```
```ruby
registry = Geo::PackageFileRegistry.find(<registry_id>)
registry.replicator.verify_async
```
- Reverify a package file, asynchronously, given a registry ID.
Since GitLab 16.2, a component can be asynchronously reverified as follows:
#### For repository types
```ruby
registry = Geo::PackageFileRegistry.find(registry_id)
registry.replicator.verify_async
```
WARNING:
Commands that change data can cause damage if not run correctly or under the right conditions. Always run commands in a test environment first and have a backup instance ready to restore.
- **For Repository types** (using the `SnippetRepository` component as an example)
[Start a Rails console session](../../../../administration/operations/rails_console.md#starting-a-rails-console-session)
on a **secondary site**.
- Resync a snippet repository, synchronously, given an ID:
Using the `SnippetRepository` component as an example:
```ruby
model_record = Geo::SnippetRepositoryRegistry.find(id)
model_record.replicator.sync
```
- Resync a snippet repository, synchronously, given an ID:
- Resync a snippet repository, synchronously, given a registry ID
```ruby
model_record = Geo::SnippetRepositoryRegistry.find(<id>)
model_record.replicator.sync
```
```ruby
registry = Geo::SnippetRepositoryRegistry.find(registry_id)
registry.replicator.sync
```
- Resync a snippet repository, synchronously, given a registry ID:
- Resync a snippet repository, asynchronously, given a registry ID.
Since GitLab 16.2, a component can be asynchronously replicated as follows:
```ruby
registry = Geo::SnippetRepositoryRegistry.find(<registry_id>)
registry.replicator.sync
```
```ruby
registry = Geo::SnippetRepositoryRegistry.find(registry_id)
registry.replicator.enqueue_sync
```
- Since GitLab 16.2, a component can be asynchronously replicated. Resync a
snippet repository, asynchronously, given a registry ID:
- Reverify a snippet repository, asynchronously, given a registry ID.
Since GitLab 16.2, a component can be asynchronously reverified as follows:
```ruby
registry = Geo::SnippetRepositoryRegistry.find(<registry_id>)
registry.replicator.enqueue_sync
```
```ruby
registry = Geo::SnippetRepositoryRegistry.find(registry_id)
registry.replicator.verify_async
```
- Since GitLab 16.2, a component can be asynchronously reverified. Reverify a
snippet repository, asynchronously, given a registry ID:
```ruby
registry = Geo::SnippetRepositoryRegistry.find(<registry_id>)
registry.replicator.verify_async
```
### Resync and reverify multiple components
NOTE:
There is an [issue to implement this functionality in the **Admin** area UI](https://gitlab.com/gitlab-org/gitlab/-/issues/364729).
> - Bulk resync and reverify [added](https://gitlab.com/gitlab-org/gitlab/-/issues/364729) in GitLab 16.5.
WARNING:
Commands that change data can cause damage if not run correctly or under the right conditions. Always run commands in a test environment first and have a backup instance ready to restore.
@ -300,13 +309,13 @@ To validate if you are experiencing this issue:
1. In the same Rails console, resync an affected project:
```ruby
Project.find_by_full_path('mygroup/mysubgroup/myproject').replicator.resync
Project.find_by_full_path('<mygroup/mysubgroup/myproject>').replicator.resync
```
1. Look at the sync state:
```ruby
Project.find_by_full_path('mygroup/mysubgroup/myproject').replicator.registry
Project.find_by_full_path('<mygroup/mysubgroup/myproject>').replicator.registry
```
1. If `last_sync_failure` no longer includes the error `fatal: could not read Username`, then you are

4
doc/administration/geo/replication/upgrading_the_geo_sites.md
View File

@ -38,12 +38,12 @@ and all **secondary** sites:
1. Optional. [Pause replication on each **secondary** site](../replication/pause_resume_replication.md)
to protect the disaster recovery (DR) capability of the **secondary** sites.
1. SSH into each node of the **primary** site.
1. [Upgrade GitLab on the **primary** site](../../../update/package/index.md#upgrade-using-the-official-repositories).
1. [Upgrade GitLab on the **primary** site](../../../update/package/index.md#by-using-the-official-repositories-recommended).
1. Perform testing on the **primary** site, particularly if you paused replication in step 1 to protect DR.
[There are some suggestions for post-upgrade testing](../../../update/index.md#pre-upgrade-and-post-upgrade-checks) in the upgrade documentation.
1. Ensure that the secrets in the `/etc/gitlab/gitlab-secrets.json` file of both the primary site and the secondary site are the same. The file must be the same on all of a site's nodes.
1. SSH into each node of **secondary** sites.
1. [Upgrade GitLab on each **secondary** site](../../../update/package/index.md#upgrade-using-the-official-repositories).
1. [Upgrade GitLab on each **secondary** site](../../../update/package/index.md#by-using-the-official-repositories-recommended).
1. If you paused replication in step 1, [resume replication on each **secondary**](../index.md#pausing-and-resuming-replication).
Then, restart Puma and Sidekiq on each **secondary** site. This is to ensure they
are initialized against the newer database schema that is now replicated from

2
doc/api/environments.md
View File

@ -207,7 +207,7 @@ POST /projects/:id/environments
| `tier` | string | no | The tier of the new environment. Allowed values are `production`, `staging`, `testing`, `development`, and `other`. |
| `cluster_agent_id` | integer | no | The cluster agent to associate with this environment. |
| `kubernetes_namespace` | string | no | The Kubernetes namespace to associate with this environment. |
| `flux_resource_path` | string | no | The Flux resource path to associate with this environment. |
| `flux_resource_path` | string | no | The Flux resource path to associate with this environment. This must be the full resource path. For example, `helm.toolkit.fluxcd.io/v2/namespaces/gitlab-agent/helmreleases/gitlab-agent`. |
```shell
curl --data "name=deploy&external_url=https://deploy.gitlab.example.com" \

4
doc/api/runners.md
View File

@ -587,7 +587,7 @@ Example response:
## List project's runners
List all runners available in the project, including from ancestor groups and [any allowed shared runners](../ci/runners/runners_scope.md#enable-instance-runners-for-a-project).
List all runners available in the project, including from ancestor groups and [any allowed instance runners](../ci/runners/runners_scope.md#enable-instance-runners-for-a-project).
Prerequisites:
@ -738,7 +738,7 @@ curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://git
## List group's runners
List all runners available in the group as well as its ancestor groups, including [any allowed shared runners](../ci/runners/runners_scope.md#enable-instance-runners-for-a-group).
List all runners available in the group as well as its ancestor groups, including [any allowed instance runners](../ci/runners/runners_scope.md#enable-instance-runners-for-a-group).
Prerequisites:

2
doc/development/duo_workflow/index.md
View File

@ -6,7 +6,7 @@ info: Any user with at least the Maintainer role can merge updates to this conte
# Setting up local development for Duo Workflow
Alternative to this detailed setup you can also [set up Duo Workflow directly with GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/duo_workflow.md?ref_type=heads).
This detailed guide describes setting up the local development environment for [Duo Workflow](../../user/duo_workflow/index.md). Alternatively, you can also [set up Duo Workflow directly with GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/duo_workflow.md?ref_type=heads).
## Prerequisites

6
doc/development/sql.md
View File

@ -645,7 +645,9 @@ If your code is generally isolated (for example it's executed in a worker only)
Additionally, we have a RuboCop rule `Performance/ActiveRecordSubtransactionMethods` that prevents the usage of `.safe_find_or_create_by`. This rule can be disabled on a case by case basis via `# rubocop:disable Performance/ActiveRecordSubtransactionMethods`.
## Alternative 1: `UPSERT`
### Alternatives to .find_or_create_by
#### Alternative 1: `UPSERT`
The [`.upsert`](https://api.rubyonrails.org/v7.0.5/classes/ActiveRecord/Persistence/ClassMethods.html#method-i-upsert) method can be an alternative solution when the table is backed by a unique index.
@ -695,7 +697,7 @@ To work around this, we have two options:
- Remove the uniqueness validation from the `ActiveRecord` model.
- Use the [`on` keyword](https://guides.rubyonrails.org/active_record_validations.html#on) and implement context-specific validation.
### Alternative 2: Check existence and rescue
#### Alternative 2: Check existence and rescue
When the chance of concurrently creating the same record is very low, we can use a simpler approach:

7
doc/development/testing_guide/unhealthy_tests.md
View File

@ -468,6 +468,13 @@ For tests that are slow for a legitimate reason and to skip issue creation, add
| 2023-02-15 | 67.42 seconds | 44.66 seconds | - | 76.86 seconds | Top slow test eliminating the maximum |
| 2023-06-15 | 50.13 seconds | 19.20 seconds | 27.12 | 45.40 seconds | Avg for top 100 slow tests|
## Handling issues for flaky or slow tests
The process around these issues is very lightweight. Feel free to close them or not, they're [managed automatically](https://gitlab.com/gitlab-org/ruby/gems/gitlab_quality-test_tooling/-/blob/main/lib/gitlab_quality/test_tooling/report/flaky_test_issue.rb):
- If a flaky or slow test is fixed and the associated `[Test]` issue isn't closed manually, it will be closed automatically after [30 days of inactivity](https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/policies/stages/hygiene/close-stale-unhealthy-test-issues.yml).
- If the problem reoccurs, the closed issue is reopened automatically. This means, it is also okay to close an issue when you think you fixed it.
---
[Return to Testing documentation](index.md)

13
doc/policy/maintenance.md
View File

@ -46,20 +46,21 @@ The following table describes the version types and their release cadence:
We encourage everyone to run the [latest stable release](https://about.gitlab.com/releases/categories/releases/)
to ensure that you can upgrade to the most secure and feature-rich GitLab experience.
To make sure you can run the most recent stable release, we are working
hard to keep the update process simple and reliable.
hard to keep the update process reliable.
If you are unable to follow our monthly release cycle, there are a couple of
cases you must consider. Follow the
[upgrade paths guide](../update/upgrade_paths.md) to safely upgrade
between versions.
NOTE:
Version specific changes in Linux packages can be found in [the Linux package documentation](../update/package/index.md#version-specific-changes).
Version-specific change documentation for Linux packages is available for:
NOTE:
Instructions are available for downloading the Linux package locally and [manually installing](../update/package/index.md#download-a-package-manually) it.
- [GitLab 17](../update/versions/gitlab_17_changes.md)
- [GitLab 16](../update/versions/gitlab_16_changes.md)
- [GitLab 15](../update/versions/gitlab_15_changes.md)
Instructions are available for downloading the Linux package locally and [manually installing](../update/package/index.md#by-using-a-downloaded-package) it.
NOTE:
A step-by-step guide to [upgrading the Linux package-bundled PostgreSQL is documented separately](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server).
## Upgrading major versions

4
doc/topics/offline/quick_start_guide.md
View File

@ -25,7 +25,7 @@ For a video walkthrough of this process, see [Offline GitLab Installation: Downl
### Download the GitLab package
You should [manually download the GitLab package](../../update/package/index.md#download-a-package-manually) and relevant dependencies using a server of the same operating system type that has access to the Internet.
You should [manually download the GitLab package](../../update/package/index.md#by-using-a-downloaded-package) and relevant dependencies using a server of the same operating system type that has access to the Internet.
If your offline environment has no local network access, you must manually transport the relevant package through physical media, such as a USB drive.
@ -58,7 +58,7 @@ sudo cd /path/to/mount
sudo dpkg -i <package_name>.deb
```
[Use the relevant commands for your operating system to install the package](../../update/package/index.md#download-a-package-manually) but make sure to specify an `http`
[Use the relevant commands for your operating system to install the package](../../update/package/index.md#by-using-a-downloaded-package) but make sure to specify an `http`
URL for the `EXTERNAL_URL` installation step. Once installed, we can manually
configure the SSL ourselves.

21
doc/update/index.md
View File

@ -33,6 +33,9 @@ To upgrade GitLab:
1. Determine what [upgrade path](upgrade_paths.md) you should take. Your upgrade might require multiple upgrades. If
relevant, check [OS compatibility with the target GitLab version](../administration/package_information/supported_os.md).
1. Check for [background migrations](background_migrations.md). All migrations must finish running before each upgrade.
You must spread out upgrades between major and minor releases to allow time for background migrations to finish.
1. Test your upgrade in a test environment first, and have a [rollback plan](plan_your_upgrade.md#rollback-plan)
to reduce the risk of unplanned outages and extended downtime.
1. If available in your starting version, consider [turning on maintenance mode](../administration/maintenance_mode/index.md)
during the upgrade.
1. Consult changes for different versions of GitLab to ensure compatibility before upgrading:
@ -41,7 +44,11 @@ To upgrade GitLab:
- [GitLab 15 changes](versions/gitlab_15_changes.md)
1. Perform [pre-upgrade checks](#pre-upgrade-and-post-upgrade-checks).
1. Pause [running CI/CD pipelines and jobs](#cicd-pipelines-and-jobs-during-upgrades).
1. Follow [upgrade steps for additional features](#upgrade-steps-for-additional-features), if relevant.
1. If relevant, follow [upgrade steps for additional features](#upgrade-steps-for-additional-features):
- [Advanced search (Elasticsearch)](#elasticsearch).
- [Geo](#geo).
- [Gitaly running on its own server](#external-gitaly).
- [GitLab agent for Kubernetes](#gitlab-agent-for-kubernetes).
1. Follow the [upgrade steps based on your installation method](#upgrade-based-on-installation-method).
1. If your GitLab instance has any runners associated with it, upgrade them to match the current GitLab version.
This step ensures [compatibility with GitLab versions](https://docs.gitlab.com/runner/#gitlab-runner-versions).
@ -60,12 +67,8 @@ official ways to upgrade GitLab:
:::TabTitle Linux packages (Omnibus)
The [package upgrade guide](package/index.md)
contains the steps needed to upgrade a package installed by official GitLab
repositories.
There are also instructions when you want to
[upgrade to a specific version](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories).
As part of a GitLab upgrade, the [Linux package upgrade guide](package/index.md) contains the specific steps to follow
to upgrade a Linux package instance.
:::TabTitle Helm chart (Kubernetes)
@ -211,8 +214,8 @@ Some GitLab features have additional steps.
### External Gitaly
If you're using an external Gitaly server, it must be upgraded to the newer
version prior to upgrading the application server.
Upgrade Gitaly servers to the newer version before upgrading the application server. This prevents the gRPC client
on the application server from sending RPCs that the old Gitaly version does not support.
### Geo

8
doc/update/package/convert_to_ee.md
View File

@ -10,7 +10,7 @@ DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** Self-managed
To convert an existing GitLab Community Edition (CE) server installed using the Omnibus GitLab
To convert an existing GitLab Community Edition (CE) server installed using the Linux
packages to GitLab [Enterprise Edition](https://about.gitlab.com/pricing/) (EE), you install the EE
package on top of CE.
@ -28,7 +28,7 @@ The steps can be summed up to:
1. Make a [GitLab backup](../../administration/backup_restore/backup_gitlab.md).
1. Find the currently installed GitLab version:
1. Find the installed GitLab version:
**For Debian/Ubuntu**
@ -72,7 +72,7 @@ The steps can be summed up to:
NOTE:
If you want to use `dpkg`/`rpm` instead of `apt-get`/`yum`, go through the first
step to find the current GitLab version, then follow
[Upgrade using a manually downloaded package](index.md#download-a-package-manually),
[Upgrade using a manually downloaded package](index.md#by-using-a-downloaded-package),
and then [add your license](../../administration/license.md).
1. Install the `gitlab-ee` package. The install automatically
@ -123,4 +123,4 @@ The steps can be summed up to:
1. Optional. [Set up the Elasticsearch integration](../../integration/advanced_search/elasticsearch.md) to enable [advanced search](../../user/search/advanced_search.md).
That's it! You can now use GitLab Enterprise Edition! To upgrade to a newer
version, follow [Upgrade using the official repositories](index.md#upgrade-using-the-official-repositories).
version, follow [Upgrading Linux package instances](index.md).

9
doc/update/package/downgrade.md
View File

@ -25,9 +25,12 @@ The restore overwrites all newer GitLab database content with the older state.
The example below demonstrates the downgrade procedure when downgrading between minor
and patch versions (for example, from 15.0.6 to 15.0.5).
When downgrading between major versions, take into account the
[specific version changes](index.md#version-specific-changes) that occurred when you upgraded
to the major version you are downgrading from.
When downgrading between major versions, you must take into account version-specific changes that occurred when you
previously upgraded. For more information, see:
- [GitLab 17 changes](../versions/gitlab_17_changes.md)
- [GitLab 16 changes](../versions/gitlab_16_changes.md)
- [GitLab 15 changes](../versions/gitlab_15_changes.md)
These steps consist of:

82
doc/update/package/index.md
View File

@ -4,53 +4,25 @@ group: Distribution
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
---
# Upgrade GitLab by using the GitLab package
# Upgrading Linux package instances
DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** Self-managed
You can upgrade GitLab to a new version by using the
GitLab package.
## Prerequisites
- Create an [upgrade plan](../plan_your_upgrade.md).
We recommend upgrading in a test environment first and having a [rollback plan](../plan_your_upgrade.md#rollback-plan)
to reduce the risk of unplanned outages and extended downtime.
- Decide when to upgrade by viewing the [supported upgrade paths](../upgrade_paths.md).
You can't directly skip major versions (for example, go from 10.3 to 12.7 in one step).
- If you are upgrading from a non-package installation to a GitLab package installation, see
[Upgrading from a non-package installation to a GitLab package installation](https://docs.gitlab.com/omnibus/update/convert_to_omnibus.html).
- Ensure that any
[background migrations](../background_migrations.md)
are fully completed. Upgrading
before background migrations have finished can lead to data corruption.
We recommend performing upgrades between major and minor releases no more than once per
week, to allow time for background migrations to finish.
- Gitaly servers must be upgraded to the newer version prior to upgrading the application server.
This prevents the gRPC client on the application server from sending RPCs that the old Gitaly version
does not support.
Upgrading Linux package instances to a later version of GitLab requires several steps, many specific to Linux package
installations.
## Downtime
- For single node installations, GitLab is not available to users while an
upgrade is in progress. The user's web browser shows a `Deploy in progress` message or a `502` error.
upgrade is in progress. The user's web browser shows a **Deploy in progress** message or a `502` error.
- For multi-node installations, see how to perform
[zero-downtime upgrades](../zero_downtime.md).
- Upgrades to multi-node installations can also be performed
[with downtime](../with_downtime.md).
## Version-specific changes
Upgrading versions might need some manual intervention. For more information,
check the version you are upgrading to:
- [GitLab 17](../versions/gitlab_17_changes.md)
- [GitLab 16](../versions/gitlab_16_changes.md)
- [GitLab 15](../versions/gitlab_15_changes.md)
### Earlier GitLab versions
## Earlier GitLab versions
For version-specific information for earlier GitLab versions, see the [documentation archives](https://archives.docs.gitlab.com).
The versions of the documentation in the archives contain version-specific information for even earlier versions of GitLab.
@ -58,7 +30,7 @@ The versions of the documentation in the archives contain version-specific infor
For example, the [documentation for GitLab 15.11](https://archives.docs.gitlab.com/15.11/ee/update/package/#version-specific-changes)
contains information on versions back to GitLab 11.
## Back up before upgrading
## Skip automatic database backups
The GitLab database is backed up before installing a newer GitLab version. You
may skip this automatic database backup by creating an empty file
@ -68,10 +40,19 @@ at `/etc/gitlab/skip-auto-backup`:
sudo touch /etc/gitlab/skip-auto-backup
```
Nevertheless, it is highly recommended to maintain a full up-to-date
Nevertheless, you should maintain a full up-to-date
[backup](../../administration/backup_restore/index.md) on your own.
## Upgrade using the official repositories
## Upgrade a Linux package instance
To upgrade a Linux package instance:
1. [Complete the initial steps](../index.md#upgrade-gitlab) in the main GitLab upgrade documentation.
1. If you are upgrading from a non-package installation to a GitLab package installation, follow the steps in
[Upgrading from a non-package installation to a GitLab package installation](https://docs.gitlab.com/omnibus/update/convert_to_omnibus.html).
1. Continue the upgrade by following the sections below.
### By using the official repositories (recommended)
All GitLab packages are posted to the GitLab [package server](https://packages.gitlab.com/gitlab/).
Six repositories are maintained:
@ -90,10 +71,10 @@ If you have installed GitLab [Community Edition](https://about.gitlab.com/instal
or [Enterprise Edition](https://about.gitlab.com/install/), then the
official GitLab repository should have already been set up for you.
### Upgrade to the latest version using the official repositories
#### Upgrade to the latest version
If you upgrade GitLab regularly, for example once a month, you can upgrade to
the latest version by using your package manager.
If you upgrade GitLab regularly (for example, every month), you can upgrade to
the latest version by using the package manager for your Linux distribution.
To upgrade to the latest GitLab version:
@ -115,7 +96,7 @@ NOTE:
For the GitLab Community Edition, replace `gitlab-ee` with
`gitlab-ce`.
### Upgrade to a specific version using the official repositories
#### Upgrade to a specific version
Linux package managers default to installing the latest available version of a
package for installation and upgrades. Upgrading directly to the latest major
@ -171,21 +152,17 @@ NOTE:
For the GitLab Community Edition, replace `ee` with
`ce`.
## Download a package manually
### By using a downloaded package
NOTE:
The [package repository](#upgrade-using-the-official-repositories) is recommended over
a manual installation.
If for some reason you don't use the official repositories, you can
If you don't want to use the official repositories, you can
download the package and install it manually. This method can be used to either
install GitLab for the first time or upgrade it.
To download and install or upgrade GitLab:
1. Visit the [official repository](#upgrade-using-the-official-repositories) of your package.
1. Filter the list by searching for the version you want to install (for example 14.1.8).
Multiple packages may exist for a single version, one for each supported distribution
1. Go to the [official repository](#by-using-the-official-repositories-recommended) of your package.
1. Filter the list by searching for the version you want to install. For example, `14.1.8`.
Multiple packages might exist for a single version, one for each supported distribution
and architecture. Next to the filename is a label indicating the distribution,
as the filenames may be the same.
1. Find the package version you wish to install, and select the filename from the list.
@ -209,12 +186,11 @@ To download and install or upgrade GitLab:
```
NOTE:
For the GitLab Community Edition, replace `gitlab-ee` with
`gitlab-ce`.
For the GitLab Community Edition, replace `gitlab-ee` with `gitlab-ce`.
## Upgrade the product documentation
## Upgrade the product documentation (optional)
This is an optional step. If you [installed the product documentation](../../administration/docs_self_host.md),
If you [installed the product documentation](../../administration/docs_self_host.md),
see how to [upgrade to a later version](../../administration/docs_self_host.md#upgrade-using-docker).
## Troubleshooting

2
doc/update/package/package_troubleshooting.md
View File

@ -47,7 +47,7 @@ Cannot install package gitlab-ee-11.8.3-ee.0.el6.x86_64. It is obsoleted by inst
To avoid this issue, either:
- Use the same instructions provided in the
[Upgrade using a manually-downloaded package](index.md#download-a-package-manually) section.
[Upgrade using a manually-downloaded package](index.md#by-using-a-downloaded-package) section.
- Temporarily disable this checking in yum by adding `--setopt=obsoletes=0` to the options given to the command.
## 500 error when accessing Project > Settings > Repository

3
doc/update/upgrading_from_source.md
View File

@ -371,6 +371,9 @@ sudo -u git -H bundle exec rake "gitlab:workhorse:install[/home/git/gitlab-workh
### Update Gitaly
Upgrade Gitaly servers to the newer version before upgrading the application server. This prevents the gRPC client
on the application server from sending RPCs that the old Gitaly version does not support.
If Gitaly is located on its own server, or you use Gitaly Cluster, see [Zero-downtime upgrades](zero_downtime.md).
During the build process, Gitaly [compiles and embeds Git binaries](https://gitlab.com/gitlab-org/gitaly/-/issues/6089),

18
doc/update/with_downtime.md
View File

@ -80,7 +80,7 @@ kubectl scale deploy -n <namespace> -l release=<helm release name> -l 'app in (p
In summary:
1. Check the Consul nodes are all healthy.
1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories) on all your Consul servers.
1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version) on all your Consul servers.
1. Restart all GitLab services **one node at a time**:
```shell
@ -125,7 +125,7 @@ The Praefect nodes, however, can be upgraded by using an AMI redeployment proces
## Upgrade the Gitaly nodes not part of Gitaly cluster
For Gitaly servers which are not part of Gitaly cluster, [upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories).
For Gitaly servers which are not part of Gitaly cluster, [upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version).
If you have multiple Gitaly shards or have multiple load-balanced Gitaly nodes
using NFS, it doesn't matter in which order you upgrade the Gitaly servers.
@ -134,7 +134,7 @@ using NFS, it doesn't matter in which order you upgrade the Gitaly servers.
For non-clustered PostgreSQL servers:
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).
1. The upgrade process does not restart PostgreSQL when the binaries are upgraded.
Restart to load the new version:
@ -164,7 +164,7 @@ Follow the following process:
sudo gitlab-ctl patroni members
```
1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories) on one of the replica nodes.
1. [Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version) on one of the replica nodes.
1. Restart to load the new version:
@ -189,11 +189,11 @@ Follow the following process:
If you run PgBouncer on your Rails (application) nodes, then
PgBouncer are upgraded as part of the application server upgrade.
[Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories) on the PgBouncer nodes.
[Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version) on the PgBouncer nodes.
## Upgrade the Redis node
Upgrade a standalone Redis server by [upgrading the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories).
Upgrade a standalone Redis server by [upgrading the GitLab package](package/index.md#upgrade-to-a-specific-version).
## Upgrade Redis HA (using Sentinel)
@ -256,7 +256,7 @@ running all database migrations. On the deploy node:
sudo gitlab-ctl 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).
1. If you modified `gitlab.rb` on the deploy node to bypass PgBouncer:
1. Update `gitlab.rb` on the deploy node. Change `gitlab_rails['db_host']`
@ -279,7 +279,7 @@ set to anything in `gitlab.rb` on these nodes.
They can be upgraded in parallel:
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).
1. Ensure all services are restarted:
@ -305,4 +305,4 @@ kubectl scale deploy -lapp=prometheus,release=<helm release name> -n <namespace>
## Upgrade the Monitor node
[Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories).
[Upgrade the GitLab package](package/index.md#upgrade-to-a-specific-version).

18
doc/update/zero_downtime.md
View File

@ -100,7 +100,7 @@ Run through the following steps sequentially on each component's node to perform
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).
1. Reconfigure and restart to get the latest code in place:
@ -128,7 +128,7 @@ This process applies to both Gitaly Sharded and Cluster setups. Run through the
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).
1. Run the `reconfigure` command to get the latest code in place and to instruct Gitaly to gracefully reload at the next opportunity:
```shell
@ -167,7 +167,7 @@ nodes to be a deploy node. This target node will be configured to run migrations
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).
1. Ensure that `praefect['auto_migrate'] = true` is set in `/etc/gitlab/gitlab.rb` so that database migrations run.
@ -186,7 +186,7 @@ nodes to be a deploy node. This target node will be configured to run migrations
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).
1. Ensure that `praefect['auto_migrate'] = false` is set in `/etc/gitlab/gitlab.rb` to prevent
`reconfigure` from automatically running database migrations.
@ -243,7 +243,7 @@ In addition to the above, Rails is where the main database migrations need to be
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).
1. Configure regular migrations to by setting `gitlab_rails['auto_migrate'] = true` in the
`/etc/gitlab/gitlab.rb` configuration file.
@ -285,7 +285,7 @@ In addition to the above, Rails is where the main database migrations need to be
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).
1. Ensure that `gitlab_rails['auto_migrate'] = false` is set in `/etc/gitlab/gitlab.rb` to prevent
`reconfigure` from automatically running database migrations.
@ -334,7 +334,7 @@ Run through the following steps sequentially on each component node to perform t
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).
1. Run the `reconfigure` command to get the latest code in place as well as restart:
@ -408,7 +408,7 @@ below:
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).
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.
@ -458,7 +458,7 @@ below:
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).
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.

10
doc/user/duo_workflow/index.md
View File

@ -18,6 +18,16 @@ The availability of this feature is controlled by a feature flag.
For more information, see the history.
This feature is available for internal GitLab team members for testing, but not ready for production use.
WARNING:
This feature is considered [experimental](../../policy/experiment-beta-support.md) and is not intended for customer usage outside of initial design partners. We expect major changes to this feature.
DISCLAIMER:
This page contains information related to upcoming products, features, and functionality.
It is important to note that the information presented is for informational purposes only.
Please do not rely on this information for purchasing or planning purposes.
The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the
sole discretion of GitLab Inc.
Automate tasks and help increase productivity in your development workflow by using GitLab Duo Workflow.
GitLab Duo Workflow, currently only in your IDE, takes the information you provide
and uses AI to walk you through an implementation plan.

10
doc/user/gitlab_duo/index.md
View File

@ -195,10 +195,14 @@ DETAILS:
> - [Enabled on self-managed](https://gitlab.com/groups/gitlab-org/-/epics/15176) in GitLab 17.6.
> - Changed to require GitLab Duo add-on in GitLab 17.6 and later.
Self-managed users can experience a fully managed self-hosted environment, but they also have the option to use GitLab cloud connector and default AI vendors.
Use your own language models to power AI features in GitLab. Code Suggestions and Duo Chat are supported.
- **Using GitLab.com AI Gateway and Cloud Connector**: Leverage the GitLab-managed AI Gateway to connect with external large language model (LLM) providers (for example, Google Vertex AI or Anthropic), using external public providers.
- **Using a Fully Self-Hosted and Managed Solution**: Deploy and manage your own AI Gateway and LLMs entirely within your infrastructure, without depending on external public providers.
You can use language model vendors provided by GitLab or fully manage language models in your self-hosted environment.
- Use GitLab model vendors: Connect with default external model providers, like Google Vertex AI or Anthropic, by
using the GitLab-managed AI Gateway.
- Host your own models: Deploy and manage your own AI Gateway and language models in your infrastructure,
without depending on GitLab-provided external language providers.
- [View documentation](../../administration/self_hosted_models/index.md).
### Merge Request Summary

2
doc/user/group/epics/manage_epics.md
View File

@ -195,7 +195,7 @@ The assignee is changed without having to refresh the page.
## Epic color
DETAILS:
**Tier:** Ultimate
**Tier:** Premium, Ultimate
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/79940) in GitLab 14.9 [with a flag](../../../administration/feature_flags.md) named `epic_color_highlight`. Disabled by default.
> - [Enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/365336) on GitLab.com, GitLab Dedicated, and self-managed in GitLab 16.11.

3
doc/user/packages/npm_registry/index.md
View File

@ -305,7 +305,8 @@ such as `80` for a URL starting with `http` or `443` for a URL starting with `ht
In the GitLab project containing your `package.json`, edit or create a `.gitlab-ci.yml` file. For example:
```yaml
image: node:latest
default:
image: node:latest
stages:
- deploy

2
doc/user/project/merge_requests/auto_merge.md
View File

@ -48,8 +48,6 @@ Prerequisites:
- If your project configuration requires it, all threads in the
merge request [must be resolved](index.md#resolve-a-thread).
- The merge request must have received all required approvals.
- Merge trains are not supported. For more information,
see [issue 443395](https://gitlab.com/gitlab-org/gitlab/-/issues/443395).
To do this when pushing from the command line, use the `merge_request.merge_when_pipeline_succeeds`
[push option](../../../topics/git/commit.md#push-options).

2
package.json
View File

@ -255,7 +255,7 @@
"devDependencies": {
"@eslint/eslintrc": "^3.1.0",
"@eslint/js": "^9.13.0",
"@gitlab/eslint-plugin": "20.4.1",
"@gitlab/eslint-plugin": "20.5.0",
"@gitlab/stylelint-config": "6.2.2",
"@graphql-eslint/eslint-plugin": "3.20.1",
"@originjs/vite-plugin-commonjs": "^1.0.3",

2
scripts/failed_tests.rb
View File

@ -5,7 +5,7 @@ require 'optparse'
require 'fileutils'
require 'uri'
require 'json'
require 'set' # rubocop:disable Lint/RedundantRequireStatement -- Ruby 3.1 and earlier needs this. Drop this line after Ruby 3.2+ is only supported.
require 'set' # -- Ruby 3.1 and earlier needs this. Drop this line after Ruby 3.2+ is only supported.
class FailedTests
DEFAULT_OPTIONS = {

2
scripts/feature_flags/used-feature-flags
View File

@ -1,7 +1,7 @@
#!/usr/bin/env ruby
# frozen_string_literal: true
require 'set' # rubocop:disable Lint/RedundantRequireStatement -- Ruby 3.1 and earlier needs this. Drop this line after Ruby 3.2+ is only supported.
require 'set' # -- Ruby 3.1 and earlier needs this. Drop this line after Ruby 3.2+ is only supported.
require 'fileutils'
require_relative '../../lib/gitlab_edition'

2
scripts/generate_rspec_pipeline.rb
View File

@ -104,7 +104,7 @@ class GenerateRspecPipeline
def rspec_files_per_test_level
@rspec_files_per_test_level ||= begin
all_remaining_rspec_files = all_rspec_files.dup
TEST_LEVELS.each_with_object(Hash.new { |h, k| h[k] = {} }) do |test_level, memo| # rubocop:disable Rails/IndexWith
TEST_LEVELS.each_with_object(Hash.new { |h, k| h[k] = {} }) do |test_level, memo|
memo[test_level][:files] = all_remaining_rspec_files
.grep(test_level_service.regexp(test_level, true))
.tap { |files| files.each { |file| all_remaining_rspec_files.delete(file) } }

2
scripts/merge-auto-explain-logs
View File

@ -2,7 +2,7 @@
# frozen_string_literal: true
require 'json'
require 'set' # rubocop:disable Lint/RedundantRequireStatement -- Ruby 3.1 and earlier needs this. Drop this line after Ruby 3.2+ is only supported.
require 'set' # -- Ruby 3.1 and earlier needs this. Drop this line after Ruby 3.2+ is only supported.
require 'zlib'
# Load query analyzers

6
scripts/security-harness
View File

@ -45,13 +45,13 @@ def lefthook_hook_in_place?
end
def lefthook_available?
system('bundle exec lefthook run prepare-commit-msg &>/dev/null') # rubocop:disable GitlabSecurity/SystemCommandInjection
system('bundle exec lefthook run prepare-commit-msg &>/dev/null')
end
def uninstall_lefthook
return unless lefthook_available?
system('bundle exec lefthook uninstall') # rubocop:disable GitlabSecurity/SystemCommandInjection
system('bundle exec lefthook uninstall')
# `bundle exec lefthook uninstall` removes the `lefthook.yml` file so we checkout it again
system("git checkout -- #{LEFTHOOK_GLOBAL_CONFIG_PATH}") # rubocop:disable GitlabSecurity/SystemCommandInjection
puts "#{SHELL_YELLOW}Lefthook was uninstalled to let the security harness work properly.#{SHELL_CLEAR}"
@ -60,7 +60,7 @@ end
def install_lefthook
return unless lefthook_available?
system('bundle exec lefthook install') # rubocop:disable GitlabSecurity/SystemCommandInjection
system('bundle exec lefthook install')
puts "#{SHELL_GREEN}Lefthook was re-installed.#{SHELL_CLEAR}"
end

2
scripts/setup/generate-as-if-foss-env.rb
View File

@ -16,7 +16,7 @@ else
end
end
require 'set' # rubocop:disable Lint/RedundantRequireStatement -- Ruby 3.1 and earlier needs this. Drop this line after Ruby 3.2+ is only supported.
require 'set' # -- Ruby 3.1 and earlier needs this. Drop this line after Ruby 3.2+ is only supported.
class GenerateAsIfFossEnv
PARALLEL = %r{(?: \d+/\d+)}

2
scripts/verify-tff-mapping
View File

@ -1,7 +1,7 @@
#!/usr/bin/env ruby
# frozen_string_literal: true
require 'set' # rubocop:disable Lint/RedundantRequireStatement -- Ruby 3.1 and earlier needs this. Drop this line after Ruby 3.2+ is only supported.
require 'set' # -- Ruby 3.1 and earlier needs this. Drop this line after Ruby 3.2+ is only supported.
require 'test_file_finder'
# These tests run a sanity check on the mapping file `tests.yml`

2
tooling/danger/ignored_model_columns.rb
View File

@ -39,7 +39,7 @@ module Tooling
_, index = file_lines.each_with_index.find do |file_line, index|
next unless lines_to_search.include?(index)
file_line == searched_line && !exclude_indexes.include?(index) # rubocop:disable Rails/NegateInclude
file_line == searched_line && !exclude_indexes.include?(index)
end
index

2
tooling/danger/suggestor.rb
View File

@ -39,7 +39,7 @@ module Tooling
def find_line_number(file_lines, searched_line, exclude_indexes: [])
_, index = file_lines.each_with_index.find do |file_line, index|
file_line == searched_line && !exclude_indexes.include?(index) # rubocop:disable Rails/NegateInclude
file_line == searched_line && !exclude_indexes.include?(index)
end
index

2
tooling/lib/tooling/check_ruby_syntax.rb
View File

@ -1,6 +1,6 @@
# frozen_string_literal: true
require 'set' # rubocop:disable Lint/RedundantRequireStatement -- Ruby 3.1 and earlier needs this. Drop this line after Ruby 3.2+ is only supported.
require 'set' # -- Ruby 3.1 and earlier needs this. Drop this line after Ruby 3.2+ is only supported.
module Tooling
# Checks passed files for valid Ruby syntax.

4
tooling/lib/tooling/helm3_client.rb
View File

@ -41,7 +41,7 @@ module Tooling
def run_command(command)
final_command = ['helm', *command]
final_command_str = final_command.join(' ')
puts "Running command: `#{final_command_str}`" # rubocop:disable Rails/Output -- Only review apps calls this
puts "Running command: `#{final_command_str}`"
result = Gitlab::Popen.popen_with_detail(final_command)
@ -71,7 +71,7 @@ module Tooling
Release.new(release.slice(*RELEASE_JSON_ATTRIBUTES))
end
rescue ::JSON::ParserError => ex
puts "Ignoring this JSON parsing error: #{ex}\n\nResponse was:\n#{response}" # rubocop:disable Rails/Output
puts "Ignoring this JSON parsing error: #{ex}\n\nResponse was:\n#{response}"
[]
end

2
tooling/lib/tooling/test_map_generator.rb
View File

@ -1,6 +1,6 @@
# frozen_string_literal: true
require 'set' # rubocop:disable Lint/RedundantRequireStatement -- Ruby 3.1 and earlier needs this. Drop this line after Ruby 3.2+ is only supported.
require 'set' # -- Ruby 3.1 and earlier needs this. Drop this line after Ruby 3.2+ is only supported.
require 'yaml'
module Tooling

2
tooling/quality/test_level.rb
View File

@ -76,7 +76,7 @@ module Quality
end
def pattern(level)
@patterns[level] ||= "#{prefixes_for_pattern}spec/#{folders_pattern(level)}{,/**/}*#{suffix(level)}".freeze # rubocop:disable Style/RedundantFreeze
@patterns[level] ||= "#{prefixes_for_pattern}spec/#{folders_pattern(level)}{,/**/}*#{suffix(level)}".freeze
end
def regexp(level, start_with = false)

8
yarn.lock
View File

@ -1354,10 +1354,10 @@
core-js "^3.29.1"
mitt "^3.0.1"
"@gitlab/eslint-plugin@20.4.1":
version "20.4.1"
resolved "https://registry.yarnpkg.com/@gitlab/eslint-plugin/-/eslint-plugin-20.4.1.tgz#79cf7679528a1769d32faf20bab9ac9614aebf8a"
integrity sha512-OXCP04WFYa7TkVNXb2gFcgW4BlS2jvlQ/xk7BbvZ3vuHBGzQH9v6Hec709bVJ25iKe2mpHi2C4V5RMaiZUeZew==
"@gitlab/eslint-plugin@20.5.0":
version "20.5.0"
resolved "https://registry.yarnpkg.com/@gitlab/eslint-plugin/-/eslint-plugin-20.5.0.tgz#c8de1256345932d933af9712613522e4bc4464b7"
integrity sha512-QNI/Lu0NZjHLTaWrhyKez03Cpc2ia87U32Xt1wtneEdghrScxRfbL+pgoVmiEZjzyaPg8LjTtmTWkPHgoDb0sQ==
dependencies:
"@typescript-eslint/eslint-plugin" "^7.14.1"
eslint-config-airbnb-base "^15.0.0"