Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
b9b0853302
commit
feebcf1ac5
|
|
@ -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'
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
<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.',
|
||||
)
|
||||
}}
|
||||
</p>
|
||||
|
||||
<hr aria-hidden="true" />
|
||||
</template>
|
||||
</page-heading>
|
||||
|
||||
<runner-create-form
|
||||
:runner-type="$options.GROUP_TYPE"
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
<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.',
|
||||
)
|
||||
}}
|
||||
</p>
|
||||
|
||||
<hr aria-hidden="true" />
|
||||
</template>
|
||||
</page-heading>
|
||||
|
||||
<runner-create-form
|
||||
:runner-type="$options.PROJECT_TYPE"
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -66,13 +66,38 @@ 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:
|
||||
|
||||
|
|
@ -80,29 +105,6 @@ to enact the following, basic troubleshooting steps:
|
|||
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:
|
||||
|
||||
```plaintext
|
||||
CiSecureFileRegistry
|
||||
ContainerRepositoryRegistry
|
||||
DependencyProxyBlobRegistry
|
||||
DependencyProxyManifestRegistry
|
||||
JobArtifactRegistry
|
||||
LfsObjectRegistry
|
||||
MergeRequestDiffRegistry
|
||||
PackageFileRegistry
|
||||
PagesDeploymentRegistry
|
||||
PipelineArtifactRegistry
|
||||
ProjectWikiRepositoryRegistry
|
||||
SnippetRepositoryRegistry
|
||||
TerraformStateVersionRegistry
|
||||
UploadRegistry
|
||||
```
|
||||
|
||||
- Find registry records that are missing on the primary site:
|
||||
|
||||
```ruby
|
||||
|
|
@ -112,14 +114,14 @@ to enact the following, basic troubleshooting steps:
|
|||
- Resync a package file, synchronously, given an ID:
|
||||
|
||||
```ruby
|
||||
model_record = Packages::PackageFile.find(id)
|
||||
model_record = Packages::PackageFile.find(<id>)
|
||||
model_record.replicator.sync
|
||||
```
|
||||
|
||||
- Resync a package file, synchronously, given a registry ID:
|
||||
|
||||
```ruby
|
||||
registry = Geo::PackageFileRegistry.find(registry_id)
|
||||
registry = Geo::PackageFileRegistry.find(<registry_id>)
|
||||
registry.replicator.sync
|
||||
```
|
||||
|
||||
|
|
@ -127,7 +129,7 @@ to enact the following, basic troubleshooting steps:
|
|||
Since GitLab 16.2, a component can be asynchronously replicated as follows:
|
||||
|
||||
```ruby
|
||||
registry = Geo::PackageFileRegistry.find(registry_id)
|
||||
registry = Geo::PackageFileRegistry.find(<registry_id>)
|
||||
registry.replicator.enqueue_sync
|
||||
```
|
||||
|
||||
|
|
@ -135,46 +137,53 @@ to enact the following, basic troubleshooting steps:
|
|||
Since GitLab 16.2, a component can be asynchronously reverified as follows:
|
||||
|
||||
```ruby
|
||||
registry = Geo::PackageFileRegistry.find(registry_id)
|
||||
registry = Geo::PackageFileRegistry.find(<registry_id>)
|
||||
registry.replicator.verify_async
|
||||
```
|
||||
|
||||
- **For Repository types** (using the `SnippetRepository` component as an example)
|
||||
#### For repository 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)
|
||||
on a **secondary site**.
|
||||
|
||||
Using the `SnippetRepository` component as an example:
|
||||
|
||||
- Resync a snippet repository, synchronously, given an ID:
|
||||
|
||||
```ruby
|
||||
model_record = Geo::SnippetRepositoryRegistry.find(id)
|
||||
model_record = Geo::SnippetRepositoryRegistry.find(<id>)
|
||||
model_record.replicator.sync
|
||||
```
|
||||
|
||||
- Resync a snippet repository, synchronously, given a registry ID
|
||||
- Resync a snippet repository, synchronously, given a registry ID:
|
||||
|
||||
```ruby
|
||||
registry = Geo::SnippetRepositoryRegistry.find(registry_id)
|
||||
registry = Geo::SnippetRepositoryRegistry.find(<registry_id>)
|
||||
registry.replicator.sync
|
||||
```
|
||||
|
||||
- Resync a snippet repository, asynchronously, given a registry ID.
|
||||
Since GitLab 16.2, a component can be asynchronously replicated as follows:
|
||||
- Since GitLab 16.2, a component can be asynchronously replicated. Resync a
|
||||
snippet repository, asynchronously, given a registry ID:
|
||||
|
||||
```ruby
|
||||
registry = Geo::SnippetRepositoryRegistry.find(registry_id)
|
||||
registry = Geo::SnippetRepositoryRegistry.find(<registry_id>)
|
||||
registry.replicator.enqueue_sync
|
||||
```
|
||||
|
||||
- Reverify a snippet repository, asynchronously, given a registry ID.
|
||||
Since GitLab 16.2, a component can be asynchronously reverified as follows:
|
||||
- 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 = 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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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" \
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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),
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -305,6 +305,7 @@ 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
|
||||
default:
|
||||
image: node:latest
|
||||
|
||||
stages:
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
|
|
|||
|
|
@ -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",
|
||||
|
|
|
|||
|
|
@ -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 = {
|
||||
|
|
|
|||
|
|
@ -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'
|
||||
|
||||
|
|
|
|||
|
|
@ -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,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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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+)}
|
||||
|
|
|
|||
|
|
@ -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`
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
Loading…
Reference in New Issue