Add latest changes from gitlab-org/gitlab@master

app/assets/javascripts/token_access/components/inbound_token_access.vue

@@ -21,9 +21,9 @@ import TokenProjectsTable from './token_projects_table.vue';
 
 export default {
   i18n: {
-    toggleLabelTitle: s__('CICD|Allow access to this project with a CI_JOB_TOKEN'),
+    toggleLabelTitle: s__('CICD|Limit access %{italicStart}to%{italicEnd} this project'),
     toggleHelpText: s__(
-      `CICD|Manage which projects can use their CI_JOB_TOKEN to access this project. It is a security risk to disable this feature, because unauthorized projects might attempt to retrieve an active token and access the API. %{linkStart}Learn more.%{linkEnd}`,
+      `CICD|Prevent access to this project from other project CI/CD job tokens, unless the other project is added to the allowlist. It is a security risk to disable this feature, because unauthorized projects might attempt to retrieve an active token and access the API. %{linkStart}Learn more.%{linkEnd}`,
     ),
     cardHeaderTitle: s__(
       'CICD|Allow CI job tokens from the following projects to access this project',
@@ -209,6 +209,13 @@ export default {
         :label="$options.i18n.toggleLabelTitle"
         @change="updateCIJobTokenScope"
       >
+        <template #label>
+          <gl-sprintf :message="$options.i18n.toggleLabelTitle">
+            <template #italic="{ content }">
+              <i>{{ content }}</i>
+            </template>
+          </gl-sprintf>
+        </template>
         <template #help>
           <gl-sprintf :message="$options.i18n.toggleHelpText">
             <template #link="{ content }">

app/assets/javascripts/token_access/components/outbound_token_access.vue

@@ -23,9 +23,11 @@ import TokenProjectsTable from './token_projects_table.vue';
 // Note: This component will be removed in 17.0, as the outbound access token is getting deprecated
 export default {
   i18n: {
-    toggleLabelTitle: s__('CICD|Limit CI_JOB_TOKEN access'),
+    toggleLabelTitle: s__(
+      'CICD|Limit access %{italicStart}from%{italicEnd} this project (Deprecated)',
+    ),
     toggleHelpText: s__(
-      `CICD|Select the projects that can be accessed by API requests authenticated with this project's CI_JOB_TOKEN CI/CD variable. It is a security risk to disable this feature, because unauthorized projects might attempt to retrieve an active token and access the API. %{linkStart}Learn more.%{linkEnd}`,
+      `CICD|Prevent CI/CD job tokens from this project from being used to access other projects unless the other project is added to the allowlist. It is a security risk to disable this feature, because unauthorized projects might attempt to retrieve an active token and access the API. %{linkStart}Learn more.%{linkEnd}`,
     ),
     cardHeaderTitle: s__('CICD|Add an existing project to the scope'),
     settingDisabledMessage: s__(
@@ -246,6 +248,13 @@ export default {
         :disabled="disableTokenToggle"
         @change="updateCIJobTokenScope"
       >
+        <template #label>
+          <gl-sprintf :message="$options.i18n.toggleLabelTitle">
+            <template #italic="{ content }">
+              <i>{{ content }}</i>
+            </template>
+          </gl-sprintf>
+        </template>
         <template #help>
           <gl-sprintf :message="$options.i18n.toggleHelpText">
             <template #link="{ content }">

app/assets/stylesheets/page_bundles/merge_requests.scss

@@ -836,6 +836,10 @@ $tabs-holder-z-index: 250;
   background-color: var(--gray-10, $gray-10);
   container-name: mr-widget-extension;
   container-type: inline-size;
+  // Adds a fix for the view app dropdown not showing up
+  // correctly.
+  @include gl-relative;
+  @include gl-z-index-1;
 
   &.clickable:hover {
     background-color: var(--gray-50, $gray-50);

app/workers/ci/pipeline_success_unlock_artifacts_worker.rb

@@ -3,14 +3,16 @@
 module Ci
   class PipelineSuccessUnlockArtifactsWorker
     include ApplicationWorker
+    include PipelineBackgroundQueue
 
     data_consistency :always
 
     sidekiq_options retry: 3
-    include PipelineBackgroundQueue
 
     idempotent!
 
+    defer_on_database_health_signal :gitlab_ci, [:ci_job_artifacts]
+
     def perform(pipeline_id)
       ::Ci::Pipeline.find_by_id(pipeline_id).try do |pipeline|
         # TODO: Move this check inside the Ci::UnlockArtifactsService

app/workers/concerns/worker_attributes.rb

@@ -197,10 +197,10 @@ module WorkerAttributes
       !!get_class_attribute(:big_payload)
     end
 
-    def defer_on_database_health_signal(gitlab_schema, delay_by = DEFAULT_DEFER_DELAY, tables = [])
+    def defer_on_database_health_signal(gitlab_schema, tables = [], delay_by = DEFAULT_DEFER_DELAY)
       set_class_attribute(
         :database_health_check_attrs,
-        { gitlab_schema: gitlab_schema, delay_by: delay_by, tables: tables }
+        { gitlab_schema: gitlab_schema, tables: tables, delay_by: delay_by }
       )
     end
 

config/settings.rb

@@ -5,6 +5,8 @@ require_relative '../lib/gitlab_settings'
 file = ENV.fetch('GITLAB_CONFIG') { Rails.root.join('config/gitlab.yml') }
 section = ENV.fetch('GITLAB_ENV') { Rails.env }
 
+GITLAB_INSTANCE_UUID_NOT_SET = 'uuid-not-set'
+
 Settings = GitlabSettings.load(file, section) do
   def gitlab_on_standard_port?
     on_standard_port?(gitlab)
@@ -212,7 +214,7 @@ Settings = GitlabSettings.load(file, section) do
   # these pings. The sidekiq job handles temporary http failures.
   def cron_for_service_ping
     # Set a default UUID for the case when the UUID hasn't been initialized.
-    uuid = Gitlab::CurrentSettings.uuid || 'uuid-not-set'
+    uuid = Gitlab::CurrentSettings.uuid || GITLAB_INSTANCE_UUID_NOT_SET
 
     minute = Digest::SHA256.hexdigest(uuid + 'minute').to_i(16) % 60
     hour = Digest::SHA256.hexdigest(uuid + 'hour').to_i(16) % 24

config/sidekiq_queues.yml

@@ -637,6 +637,8 @@
   - 1
 - - vulnerabilities_statistics_adjustment
   - 1
+- - vulnerabilities_update_namespace_ids_of_vulnerability_reads
+  - 1
 - - vulnerability_exports_export
   - 1
 - - vulnerability_exports_export_deletion

data/deprecations/15-9-insecure-ci-job-token.yml

@@ -18,6 +18,8 @@
     In 17.0, we plan to remove the **Limit** setting completely, and set the **Allow access** setting to enabled for all projects. This change ensures a higher level of security between projects. If you currently use the **Limit** setting, you should update your projects to use the **Allow access** setting instead. If other projects access your project with a job token, you must add them to the **Allow access** allowlist.
 
     To prepare for this change, users on GitLab.com or self-managed GitLab 15.9 or later can enable the **Allow access** setting now and add the other projects. It will not be possible to disable the setting in 17.0 or later.
+
+    In 16.3, the names of these settings were changed to clarify their meanings: the deprecated **Limit CI_JOB_TOKEN access** setting is now called **Limit access _from_ this project**, and the newer **Allow access to this project with a CI_JOB_TOKEN** setting is now called **Limit access _to_ this project**.
   #
   # OPTIONAL END OF SUPPORT FIELDS
   #

db/migrate/20230727144741_add_label_lock_on_merge.rb

@@ -0,0 +1,7 @@
+# frozen_string_literal: true
+
+class AddLabelLockOnMerge < Gitlab::Database::Migration[2.1]
+  def change
+    add_column :labels, :lock_on_merge, :boolean, default: false, null: false
+  end
+end

db/schema_migrations/20230727144741

@@ -0,0 +1 @@
+e2b2b76f54ee551e777aecbaefe51663d55ea2b305ffccc3acf5d8a2da351a63

db/structure.sql

@@ -17834,7 +17834,8 @@ CREATE TABLE labels (
     description_html text,
     type character varying,
     group_id integer,
-    cached_markdown_version integer
+    cached_markdown_version integer,
+    lock_on_merge boolean DEFAULT false NOT NULL
 );
 
 CREATE SEQUENCE labels_id_seq

doc/api/project_job_token_scopes.md

@@ -50,7 +50,9 @@ Example response:
 
 ## Patch a project's CI/CD job token access settings
 
-Patch the [**Allow access to this project with a CI_JOB_TOKEN** setting](../ci/jobs/ci_job_token.md#disable-the-job-token-scope-allowlist) (job token scope) of a project.
+> **Allow access to this project with a CI_JOB_TOKEN** setting [renamed to **Limit access _to_ this project**](https://gitlab.com/gitlab-org/gitlab/-/issues/411406) in GitLab 16.3.
+
+Patch the [**Limit access _to_ this project** setting](../ci/jobs/ci_job_token.md#disable-the-job-token-scope-allowlist) (job token scope) of a project.
 
 ```plaintext
 PATCH /projects/:id/job_token_scope

doc/ci/jobs/ci_job_token.md

@@ -105,6 +105,8 @@ access is needed.
 
 ### Disable the job token scope allowlist
 
+> **Allow access to this project with a CI_JOB_TOKEN** setting [renamed to **Limit access _to_ this project**](https://gitlab.com/gitlab-org/gitlab/-/issues/411406) in GitLab 16.3.
+
 WARNING:
 It is a security risk to disable the allowlist. A malicious user could try to compromise
 a pipeline created in an unauthorized project. If the pipeline was created by one of
@@ -122,13 +124,15 @@ To disable the job token scope allowlist:
 1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. Select **Settings > CI/CD**.
 1. Expand **Token Access**.
-1. Toggle **Allow access to this project with a CI_JOB_TOKEN** to disabled.
+1. Toggle **Limit access _to_ this project** to disabled.
    Enabled by default in new projects.
 
 You can also disable the allowlist [with the API](../../api/graphql/reference/index.md#mutationprojectcicdsettingsupdate).
 
 ### Add a project to the job token scope allowlist
 
+> **Allow access to this project with a CI_JOB_TOKEN** setting [renamed to **Limit access _to_ this project**](https://gitlab.com/gitlab-org/gitlab/-/issues/411406) in GitLab 16.3.
+
 You can add projects to the allowlist for a project. Projects added to the allowlist
 can make API calls from running pipelines by using the CI/CD job token.
 
@@ -143,7 +147,7 @@ To add a project:
 1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. Select **Settings > CI/CD**.
 1. Expand **Token Access**.
-1. Verify **Allow access to this project with a CI_JOB_TOKEN** is enabled.
+1. Verify **Limit access _to_ this project** is enabled.
 1. Under **Allow CI job tokens from the following projects to access this project**,
    add projects to the allowlist.
 
@@ -176,6 +180,8 @@ If project `B` is public or internal, you do not need to add
 
 ### Configure the job token scope
 
+> **Limit CI_JOB_TOKEN access** setting [renamed to **Limit access _from_ this project**](https://gitlab.com/gitlab-org/gitlab/-/issues/411406) in GitLab 16.3.
+
 Prerequisite:
 
 - You must not have more than 200 projects added to the token's scope.
@@ -185,7 +191,7 @@ To configure the job token scope:
 1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
 1. Select **Settings > CI/CD**.
 1. Expand **Token Access**.
-1. Toggle **Limit CI_JOB_TOKEN access** to enabled.
+1. Toggle **Limit access _from_ this project** to enabled.
 1. Optional. Add existing projects to the token's access scope. The user adding a
    project must have the Maintainer role in both projects.
 

doc/ci/troubleshooting.md

@@ -330,6 +330,8 @@ start a new pipeline to use the new configuration.
 
 ### Unable to pull image from another project
 
+> **Allow access to this project with a CI_JOB_TOKEN** setting [renamed to **Limit access _to_ this project**](https://gitlab.com/gitlab-org/gitlab/-/issues/411406) in GitLab 16.3.
+
 When a runner tries to pull an image from a private project, the job could fail with the following error:
 
 ```shell
@@ -338,7 +340,7 @@ WARNING: Failed to pull image with policy "always": Error response from daemon:
 
 This error can happen if the following are both true:
 
-- The **Allow access to this project with a CI_JOB_TOKEN** option is enabled in the private project
+- The **Limit access _to_ this project** option is enabled in the private project
   hosting the image.
 - The job attempting to fetch the image is running for a project that is not listed in
   the private project's allowlist.

doc/development/search/advanced_search_migration_styleguide.md

@@ -210,6 +210,27 @@ class MigrationName < Elastic::Migration
 end
 ```
 
+#### `Search::Elastic::MigrationReindexBasedOnSchemaVersion`
+
+Reindexes all documents in the index that stores the specified document type and updates `schema_version`.
+
+Requires the `DOCUMENT_TYPE` and `NEW_SCHEMA_VERSION` constants.
+The index mapping must have a `schema_version` integer field in a `YYMM` format.
+
+```ruby
+class MigrationName < Elastic::Migration
+  include Search::Elastic::MigrationReindexBasedOnSchemaVersion
+
+  batched!
+  batch_size 9_000
+  throttle_delay 1.minute
+
+  DOCUMENT_TYPE = WorkItem
+  NEW_SCHEMA_VERSION = 23_08
+  UPDATE_BATCH_SIZE = 100
+end
+```
+
 #### `Elastic::MigrationHelper`
 
 Contains methods you can use when a migration doesn't fit the previous examples.

doc/development/sidekiq/index.md

@@ -135,7 +135,7 @@ Sidekiq workers are deferred by two ways,
         sidekiq_options retry: 3
         include ChaosQueue
 
-        defer_on_database_health_signal :gitlab_main, 1.minute, [:users]
+        defer_on_database_health_signal :gitlab_main, [:users], 1.minute
 
         def perform(duration_s)
           Gitlab::Chaos.sleep(duration_s)

doc/integration/advanced_search/elasticsearch.md

@@ -549,6 +549,20 @@ Sometimes, you might want to abandon the unfinished reindex job and resume the i
 1. Expand **Advanced Search**.
 1. Clear the **Pause Elasticsearch indexing** checkbox.
 
+## Index integrity
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/112369) in GitLab 15.10 [with a flag](../../administration/feature_flags.md) named `search_index_integrity`. Disabled by default.
+> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/392981) in GitLab 16.0.
+> - [Enabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/392981) in GitLab 16.3.
+
+FLAG:
+On self-managed GitLab, by default this feature is available. To hide the feature, an administrator can [disable the feature flag](../../administration/feature_flags.md) named `search_index_integrity`.
+On GitLab.com, this feature is available.
+
+Index integrity detects and fixes missing repository data.
+This feature is automatically used when code searches
+scoped to a group or project return no results.
+
 ## Advanced search migrations
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/234046) in GitLab 13.6.

doc/operations/incident_management/manage_incidents.md

@@ -245,7 +245,7 @@ To configure the setting:
 1. Select the **Automatically close associated incident** checkbox.
 1. Select **Save changes**.
 
-When GitLab receives a recovery alert, it closes the associated incident.
+When GitLab receives a [recovery alert](integrations.md#recovery-alerts), it closes the associated incident.
 This action is recorded as a system note on the incident indicating that it
 was closed automatically by the GitLab Alert bot.
 

doc/update/deprecations.md

@@ -1376,6 +1376,8 @@ In 17.0, we plan to remove the **Limit** setting completely, and set the **Allow
 
 To prepare for this change, users on GitLab.com or self-managed GitLab 15.9 or later can enable the **Allow access** setting now and add the other projects. It will not be possible to disable the setting in 17.0 or later.
 
+In 16.3, the names of these settings were changed to clarify their meanings: the deprecated **Limit CI_JOB_TOKEN access** setting is now called **Limit access _from_ this project**, and the newer **Allow access to this project with a CI_JOB_TOKEN** setting is now called **Limit access _to_ this project**.
+
 </div>
 
 <div class="deprecation breaking-change" data-milestone="16.0">

doc/user/okrs.md

@@ -354,6 +354,62 @@ Prerequisites:
 By default, child OKRs are ordered by creation date.
 To reorder them, drag them around.
 
+## Confidential OKRs
+
+> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/8410) in GitLab 15.3.
+
+Confidential OKRs are [OKRs](index.md) visible only to members of a project with
+[sufficient permissions](#who-can-see-confidential-okrs).
+You can use confidential OKRs to keep security vulnerabilities private or prevent surprises from
+leaking out.
+
+### Make an OKR confidential
+
+By default, OKRs are public.
+You can make an OKR confidential when you create or edit it.
+
+Prerequisites:
+
+- You must have at least the Reporter role for the project.
+- A **confidential objective** can have only confidential
+  [child objectives or key results](#child-objectives-and-key-results):
+  - To make an objective confidential: If it has any child objectives or key results, you must first
+    make all of them confidential or remove them.
+  - To make an objective non-confidential: If it has any child objectives or key results, you must
+    first make all of them non-confidential or remove them.
+  - To add child objectives or key results to a confidential objective, you must first make them
+    confidential.
+
+#### In a new OKR
+
+When you create a new objective, a checkbox right below the text area is available to mark the
+OKR as confidential.
+
+Check that box and select **Create objective** or **Create key result** to create the OKR.
+
+#### In an existing OKR
+
+To change the confidentiality of an existing OKR:
+
+1. [Open the objective](#view-an-objective) or [key result](#view-a-key-result).
+1. In the top right corner, select the vertical ellipsis (**{ellipsis_v}**).
+1. Select **Turn on confidentiality**.
+
+### Who can see confidential OKRs
+
+When an OKR is made confidential, only users with at least the Reporter role for the project have
+access to the OKR.
+Users with Guest or [Minimal](permissions.md#users-with-minimal-access) roles can't access
+the OKR even if they were actively participating before the change.
+
+However, a user with the **Guest role** can create confidential OKRs, but can only view the ones
+that they created themselves.
+
+Users with the Guest role or non-members can read the confidential issue if they are assigned to the issue.
+When a Guest user or non-member is unassigned from a confidential issue, they can no longer view it.
+
+Confidential OKRs are hidden in search results for users without the necessary permissions.
+
 ## Two-column layout
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/415077) in GitLab 16.2 [with a flag](../administration/feature_flags.md) named `work_items_mvc_2`. Disabled by default.

doc/user/project/issues/confidential_issues.md

@@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Confidential issues **(FREE)**
 
 Confidential issues are [issues](index.md) visible only to members of a project with
-[sufficient permissions](#permissions-and-access-to-confidential-issues).
+[sufficient permissions](#who-can-see-confidential-issues).
 Confidential issues can be used by open source projects and companies alike to
 keep security vulnerabilities private or prevent surprises from leaking out.
 
@@ -51,6 +51,14 @@ for the project have access to the issue.
 Users with Guest or [Minimal](../../permissions.md#users-with-minimal-access) roles can't access
 the issue even if they were actively participating before the change.
 
+However, a user with the **Guest role** can create confidential issues, but can only view the ones
+that they created themselves.
+
+Users with the Guest role or non-members can read the confidential issue if they are assigned to the issue.
+When a Guest user or non-member is unassigned from a confidential issue, they can no longer view it.
+
+Confidential issues are hidden in search results for users without the necessary permissions.
+
 ## Confidential issue indicators
 
 Confidential issues are visually different from regular issues in a few ways.
@@ -59,7 +67,7 @@ next to the issues that are marked as confidential:
 
 ![Confidential issues index page](img/confidential_issues_index_page.png)
 
-If you don't have [enough permissions](#permissions-and-access-to-confidential-issues),
+If you don't have [enough permissions](#who-can-see-confidential-issues),
 you cannot see confidential issues at all.
 
 Likewise, while inside the issue, you can see the confidential (**{eye-slash}**) icon right next to
@@ -87,27 +95,6 @@ system note in the issue's comments:
 Although you can create confidential issues (and make existing issues confidential) in a public project, you cannot make confidential merge requests.
 Learn how to create [merge requests for confidential issues](../merge_requests/confidential.md) that prevent leaks of private data.
 
-## Permissions and access to confidential issues
-
-Access to confidential issues is by one of two routes. The general rule
-is that confidential issues are visible only to members of a project with at
-least the **Reporter role**.
-
-However, a user with the **Guest role** can create
-confidential issues, but can only view the ones that they created themselves.
-
-Users with the Guest role or non-members can read the confidential issue if they are assigned to the issue.
-When a Guest user or non-member is unassigned from a confidential issue,
-they can no longer view it.
-
-Confidential issues are hidden in search results for unprivileged users.
-For example, here's what a user with the Maintainer role and the Guest role
-sees in the project's search results:
-
-| Maintainer role | Guest role |
-|:----------------|:-----------|
-| ![Confidential issues search by maintainer](img/confidential_issues_search_master.png) | ![Confidential issues search by guest](img/confidential_issues_search_guest.png) |
-
 ## Related topics
 
 - [Merge requests for confidential issues](../merge_requests/confidential.md)

lib/gitlab/sidekiq_middleware/skip_jobs.rb

@@ -84,8 +84,8 @@ module Gitlab
         health_context = Gitlab::Database::HealthStatus::Context.new(
           DatabaseHealthStatusChecker.new(job['jid'], worker_class.name),
           job_base_model.connection,
-          health_check_attrs[:gitlab_schema],
-          health_check_attrs[:tables]
+          health_check_attrs[:tables],
+          health_check_attrs[:gitlab_schema]
         )
 
         Gitlab::Database::HealthStatus.evaluate(health_context).any?(&:stop?)

locale/gitlab.pot

@@ -8993,9 +8993,6 @@ msgstr ""
 msgid "CICD|Allow CI job tokens from the following projects to access this project"
 msgstr ""
 
-msgid "CICD|Allow access to this project with a CI_JOB_TOKEN"
-msgstr ""
-
 msgid "CICD|Auto DevOps"
 msgstr ""
 
@@ -9032,13 +9029,16 @@ msgstr ""
 msgid "CICD|Limit"
 msgstr ""
 
-msgid "CICD|Limit CI_JOB_TOKEN access"
+msgid "CICD|Limit access %{italicStart}from%{italicEnd} this project (Deprecated)"
 msgstr ""
 
-msgid "CICD|Manage which projects can use their CI_JOB_TOKEN to access this project. It is a security risk to disable this feature, because unauthorized projects might attempt to retrieve an active token and access the API. %{linkStart}Learn more.%{linkEnd}"
+msgid "CICD|Limit access %{italicStart}to%{italicEnd} this project"
 msgstr ""
 
-msgid "CICD|Select the projects that can be accessed by API requests authenticated with this project's CI_JOB_TOKEN CI/CD variable. It is a security risk to disable this feature, because unauthorized projects might attempt to retrieve an active token and access the API. %{linkStart}Learn more.%{linkEnd}"
+msgid "CICD|Prevent CI/CD job tokens from this project from being used to access other projects unless the other project is added to the allowlist. It is a security risk to disable this feature, because unauthorized projects might attempt to retrieve an active token and access the API. %{linkStart}Learn more.%{linkEnd}"
+msgstr ""
+
+msgid "CICD|Prevent access to this project from other project CI/CD job tokens, unless the other project is added to the allowlist. It is a security risk to disable this feature, because unauthorized projects might attempt to retrieve an active token and access the API. %{linkStart}Learn more.%{linkEnd}"
 msgstr ""
 
 msgid "CICD|The %{boldStart}Limit CI_JOB_TOKEN%{boldEnd} scope is deprecated and will be removed the 17.0 milestone. Configure the %{boldStart}CI_JOB_TOKEN%{boldEnd} allowlist instead. %{linkStart}How do I do this?%{linkEnd}"

spec/lib/gitlab/sidekiq_middleware/skip_jobs_spec.rb

@@ -115,7 +115,7 @@ RSpec.describe Gitlab::SidekiqMiddleware::SkipJobs, feature_category: :scalabili
     end
 
     context 'with worker opted for database health check' do
-      let(:health_signal_attrs) { { gitlab_schema: :gitlab_main, delay: 1.minute, tables: [:users] } }
+      let(:health_signal_attrs) { { gitlab_schema: :gitlab_main, tables: [:users], delay: 1.minute } }
 
       around do |example|
         with_sidekiq_server_middleware do |chain|

spec/workers/ci/pipeline_success_unlock_artifacts_worker_spec.rb

@@ -69,4 +69,43 @@ RSpec.describe Ci::PipelineSuccessUnlockArtifactsWorker, feature_category: :buil
       end
     end
   end
+
+  describe '.database_health_check_attrs' do
+    it 'defines expected db health check attrs' do
+      expect(described_class.database_health_check_attrs).to eq(
+        gitlab_schema: :gitlab_ci,
+        delay_by: described_class::DEFAULT_DEFER_DELAY,
+        tables: [:ci_job_artifacts]
+      )
+    end
+  end
+
+  context 'with stop signal from database health check' do
+    let(:pipeline_id) { non_existing_record_id }
+    let(:health_signal_attrs) { described_class.database_health_check_attrs }
+
+    around do |example|
+      with_sidekiq_server_middleware do |chain|
+        chain.add Gitlab::SidekiqMiddleware::SkipJobs
+        Sidekiq::Testing.inline! { example.run }
+      end
+    end
+
+    before do
+      stub_feature_flags("drop_sidekiq_jobs_#{described_class.name}": false)
+
+      stop_signal = instance_double("Gitlab::Database::HealthStatus::Signals::Stop", stop?: true)
+      allow(Gitlab::Database::HealthStatus).to receive(:evaluate).and_return([stop_signal])
+    end
+
+    it 'defers the job by set time' do
+      expect_next_instance_of(described_class) do |worker|
+        expect(worker).not_to receive(:perform).with(pipeline_id)
+      end
+
+      expect(described_class).to receive(:perform_in).with(health_signal_attrs[:delay_by], pipeline_id)
+
+      described_class.perform_async(pipeline_id)
+    end
+  end
 end

spec/workers/concerns/worker_attributes_spec.rb

@@ -37,7 +37,7 @@ RSpec.describe WorkerAttributes, feature_category: :shared do
       :worker_has_external_dependencies? | :worker_has_external_dependencies! | false            | []                                 | true
       :idempotent?                       | :idempotent!                       | false            | []                                 | true
       :big_payload?                      | :big_payload!                      | false            | []                                 | true
-      :database_health_check_attrs       | :defer_on_database_health_signal   | nil              | [:gitlab_main, 1.minute, [:users]] | { gitlab_schema: :gitlab_main, delay_by: 1.minute, tables: [:users] }
+      :database_health_check_attrs       | :defer_on_database_health_signal   | nil              | [:gitlab_main, [:users], 1.minute] | { gitlab_schema: :gitlab_main, tables: [:users], delay_by: 1.minute }
     end
     # rubocop: enable Layout/LineLength
 
@@ -148,7 +148,7 @@ RSpec.describe WorkerAttributes, feature_category: :shared do
 
     context 'when defer_on_database_health_signal is set' do
       before do
-        worker.defer_on_database_health_signal(:gitlab_main, 1.minute, [:users])
+        worker.defer_on_database_health_signal(:gitlab_main, [:users], 1.minute)
       end
 
       it { is_expected.to be(true) }