diff --git a/app/assets/stylesheets/page_bundles/merge_requests.scss b/app/assets/stylesheets/page_bundles/merge_requests.scss
index 697ed9e4d07..f39247f06c2 100644
--- a/app/assets/stylesheets/page_bundles/merge_requests.scss
+++ b/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);
diff --git a/app/workers/ci/pipeline_success_unlock_artifacts_worker.rb b/app/workers/ci/pipeline_success_unlock_artifacts_worker.rb
index 2a1f492cacb..2bebfdf9114 100644
--- a/app/workers/ci/pipeline_success_unlock_artifacts_worker.rb
+++ b/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
diff --git a/app/workers/concerns/worker_attributes.rb b/app/workers/concerns/worker_attributes.rb
index cc8d77e91f1..02eda924b71 100644
--- a/app/workers/concerns/worker_attributes.rb
+++ b/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
diff --git a/config/settings.rb b/config/settings.rb
index c25531a3311..3edbcc9b5ed 100644
--- a/config/settings.rb
+++ b/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
diff --git a/config/sidekiq_queues.yml b/config/sidekiq_queues.yml
index d278986266c..6f9ba5be29d 100644
--- a/config/sidekiq_queues.yml
+++ b/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
diff --git a/data/deprecations/15-9-insecure-ci-job-token.yml b/data/deprecations/15-9-insecure-ci-job-token.yml
index 5664ffee008..f807c337de8 100644
--- a/data/deprecations/15-9-insecure-ci-job-token.yml
+++ b/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
#
diff --git a/db/migrate/20230727144741_add_label_lock_on_merge.rb b/db/migrate/20230727144741_add_label_lock_on_merge.rb
new file mode 100644
index 00000000000..a352051a4ba
--- /dev/null
+++ b/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
diff --git a/db/schema_migrations/20230727144741 b/db/schema_migrations/20230727144741
new file mode 100644
index 00000000000..8d762d5db29
--- /dev/null
+++ b/db/schema_migrations/20230727144741
@@ -0,0 +1 @@
+e2b2b76f54ee551e777aecbaefe51663d55ea2b305ffccc3acf5d8a2da351a63
\ No newline at end of file
diff --git a/db/structure.sql b/db/structure.sql
index 024106a26f5..f49aba6486f 100644
--- a/db/structure.sql
+++ b/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
diff --git a/doc/api/project_job_token_scopes.md b/doc/api/project_job_token_scopes.md
index 4d1e013ee14..486149ad180 100644
--- a/doc/api/project_job_token_scopes.md
+++ b/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
diff --git a/doc/ci/jobs/ci_job_token.md b/doc/ci/jobs/ci_job_token.md
index befa9c89d72..3dcbf79b2a9 100644
--- a/doc/ci/jobs/ci_job_token.md
+++ b/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.
diff --git a/doc/ci/troubleshooting.md b/doc/ci/troubleshooting.md
index 623589e2cbc..ac5976de20a 100644
--- a/doc/ci/troubleshooting.md
+++ b/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.
diff --git a/doc/development/search/advanced_search_migration_styleguide.md b/doc/development/search/advanced_search_migration_styleguide.md
index d9ef0808c5a..10c4fa3dcc6 100644
--- a/doc/development/search/advanced_search_migration_styleguide.md
+++ b/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.
diff --git a/doc/development/sidekiq/index.md b/doc/development/sidekiq/index.md
index 936388a14fe..1b3b319ef28 100644
--- a/doc/development/sidekiq/index.md
+++ b/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)
diff --git a/doc/integration/advanced_search/elasticsearch.md b/doc/integration/advanced_search/elasticsearch.md
index 036be552ab7..a82730ea567 100644
--- a/doc/integration/advanced_search/elasticsearch.md
+++ b/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.
diff --git a/doc/operations/incident_management/manage_incidents.md b/doc/operations/incident_management/manage_incidents.md
index bb9dde4b416..73ed82bed5c 100644
--- a/doc/operations/incident_management/manage_incidents.md
+++ b/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.
diff --git a/doc/update/deprecations.md b/doc/update/deprecations.md
index 47bece45a45..be2f6386300 100644
--- a/doc/update/deprecations.md
+++ b/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**.
+
diff --git a/doc/user/okrs.md b/doc/user/okrs.md
index 6579ecbadbc..9d99d34c359 100644
--- a/doc/user/okrs.md
+++ b/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.
diff --git a/doc/user/project/issues/confidential_issues.md b/doc/user/project/issues/confidential_issues.md
index 6c2e6cb2132..f05b8412deb 100644
--- a/doc/user/project/issues/confidential_issues.md
+++ b/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:

-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 |
-|:----------------|:-----------|
-|  |  |
-
## Related topics
- [Merge requests for confidential issues](../merge_requests/confidential.md)
diff --git a/doc/user/project/issues/img/confidential_issues_search_guest.png b/doc/user/project/issues/img/confidential_issues_search_guest.png
deleted file mode 100644
index dc1b4ba8ad7..00000000000
Binary files a/doc/user/project/issues/img/confidential_issues_search_guest.png and /dev/null differ
diff --git a/doc/user/project/issues/img/confidential_issues_search_master.png b/doc/user/project/issues/img/confidential_issues_search_master.png
deleted file mode 100644
index fc01f4da9db..00000000000
Binary files a/doc/user/project/issues/img/confidential_issues_search_master.png and /dev/null differ
diff --git a/lib/gitlab/sidekiq_middleware/skip_jobs.rb b/lib/gitlab/sidekiq_middleware/skip_jobs.rb
index 8932607df52..6cc394aa5f4 100644
--- a/lib/gitlab/sidekiq_middleware/skip_jobs.rb
+++ b/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?)
diff --git a/locale/gitlab.pot b/locale/gitlab.pot
index 6fb5dc0c163..c816afad373 100644
--- a/locale/gitlab.pot
+++ b/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}"
diff --git a/spec/lib/gitlab/sidekiq_middleware/skip_jobs_spec.rb b/spec/lib/gitlab/sidekiq_middleware/skip_jobs_spec.rb
index 4be21591a40..620de7e7671 100644
--- a/spec/lib/gitlab/sidekiq_middleware/skip_jobs_spec.rb
+++ b/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|
diff --git a/spec/workers/ci/pipeline_success_unlock_artifacts_worker_spec.rb b/spec/workers/ci/pipeline_success_unlock_artifacts_worker_spec.rb
index 70821f3a833..60a34fdab53 100644
--- a/spec/workers/ci/pipeline_success_unlock_artifacts_worker_spec.rb
+++ b/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
diff --git a/spec/workers/concerns/worker_attributes_spec.rb b/spec/workers/concerns/worker_attributes_spec.rb
index 959cb62c6fb..90c07a9c959 100644
--- a/spec/workers/concerns/worker_attributes_spec.rb
+++ b/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) }