VladPolskiy/gitlab-ce
1
0
Fork 0
mirror of https://github.com/gitlabhq/gitlabhq.git synced 2025-07-20 16:42:55 +00:00
Code Issues Packages Projects Releases Wiki Activity

Add latest changes from gitlab-org/gitlab@master

Browse Source
This commit is contained in:
GitLab Bot
2025-07-18 00:09:39 +00:00
parent 9c7ce66dac
commit 950e7b01af
19 changed files with 334 additions and 142 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
GITALY_SERVER_VERSION
View File

@ -1 +1 @@
618ae0350e94d1409b05ee8af563416be9433f4a
ab88e3894dc8f759c768d0324b2614c7274dd56d

14
app/controllers/application_controller.rb
View File

@ -548,15 +548,11 @@ class ApplicationController < BaseActionController
auth_user if strong_memoized?(:auth_user)
end
def set_current_organization
return if ::Current.organization_assigned
::Current.organization = Gitlab::Current::Organization.new(
params: params.permit(
:controller, :namespace_id, :group_id, :id, :organization_path
),
user: current_user
).organization
# Used by `set_current_organization` in BaseActionController
def organization_params
params.permit(
:controller, :namespace_id, :group_id, :id, :organization_path
)
end
end

12
app/controllers/base_action_controller.rb
View File

@ -30,6 +30,18 @@ class BaseActionController < ActionController::Base
connect_src_values = Array.wrap(default_connect_src) | [Gitlab::CurrentSettings.snowplow_collector_hostname]
p.connect_src(*connect_src_values)
end
def set_current_organization
return if ::Current.organization_assigned
organization = Gitlab::Current::Organization.new(
params: organization_params,
user: current_user,
headers: request.headers
).organization
::Current.organization = organization
end
end
# rubocop:enable Gitlab/NamespacedClass
# rubocop:enable Rails/ApplicationController

5
app/controllers/oauth/authorizations_controller.rb
View File

@ -148,8 +148,9 @@ class Oauth::AuthorizationsController < Doorkeeper::AuthorizationsController
) && !doorkeeper_application&.trusted?
end
def set_current_organization
::Current.organization = Gitlab::Current::Organization.new(user: current_user).organization
# Used by `set_current_organization` in BaseActionController
def organization_params
{}
end
end

3
app/graphql/types/notes/discussion_type.rb
View File

@ -13,7 +13,8 @@ module Types
field :noteable, Types::NoteableType, null: true,
description: 'Object which the discussion belongs to.'
field :notes, Types::Notes::NoteType.connection_type, null: false,
description: 'All notes in the discussion.'
description: 'All notes in the discussion.',
max_page_size: 200
def noteable
noteable = object.noteable

108
data/whats_new/202507170001_18_02.yml Normal file
View File

@ -0,0 +1,108 @@
# What's New entries for GitLab 18.2
# File name 202507170001_18_02.yml
# Generated on Thu Jul 17 20:22:46 UTC 2025
- name: Duo Agent Platform in the IDE (Beta)
description: |
The Duo Agent Platform brings agentic chat and agent flows directly into VS Code and JetBrains IDEs, enabling natural conversation-based interaction with your codebase and GitLab projects.
Agentic chat is designed for quick, conversational tasks like creating and editing files, searching across your codebase with pattern matching and grep, and getting immediate answers about your code.
Agent flows handle larger implementations and comprehensive planning, taking high-level ideas from concept to architecture while accessing GitLab resources including issues, merge requests, commits, CI/CD pipelines, and security vulnerabilities.
Both provide intelligent search capabilities for documentation, code patterns, and project discovery to help you accomplish everything from quick edits to complex project analysis.
The platform also supports Model Context Protocol (MCP) for connecting to external data sources and tools, allowing AI features to leverage context beyond GitLab.
To get started, see the [Duo Agent Platform documentation](https://docs.gitlab.com/user/duo_agent_platform/),
[VS Code setup guide](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/#use-agentic-chat-in-vs-code),
and [JetBrains setup guide](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/#use-agentic-chat-in-jetbrains-ides).
stage: ai-powered
self-managed: true
gitlab-com: true
available_in: [Premium, Ultimate]
documentation_link: https://docs.gitlab.com/user/duo_agent_platform/
image_url: https://img.youtube.com/vi/GPewPbqlFDE/hqdefault.jpg
published_at: 2025-07-17
release: 18.2
- name: Custom workflow statuses for issues and tasks
description: |
Move beyond the basic open/closed system with configurable status that lets you track work items through
your team's actual workflow stages.
Instead of relying on labels, you can now define custom statuses that accurately
reflect your process. With configurable statuses, you can:
- **Define custom workflows** that match your team's actual process.
- **Replace workflow labels** with proper statuses that are easier to find, update, and report on.
- **Clarify completion outcomes** beyond closing an issue using "Done" or "Canceled".
- **Filter and report accurately** on work item status for better project insights.
- **Use status in issue boards** with automatic updates when issues move between columns.
- **Bulk update status** across multiple work items for efficient workflow management.
- **Track dependencies** with status visibility for linked work items.
Custom workflow statuses also support **quick actions in comments** and automatically syncs with GitLab's
open/closed system.
Help us improve this feature by sharing your thoughts and suggestions in our
[feedback issue](https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/35235).
stage: plan
self-managed: true
gitlab-com: true
available_in: [Premium, Ultimate]
documentation_link: https://docs.gitlab.com/user/work_items/status/
image_url: https://img.youtube.com/vi/oxN95MSo6UU/hqdefault.jpg
published_at: 2025-07-17
release: 18.2
- name: New merge request homepage
description: |
Managing code reviews across multiple projects can be overwhelming when you're juggling dozens of merge requests
as both an author and reviewer.
The new merge request homepage transforms how you navigate your review workload
by intelligently prioritizing what needs your attention right now, with two powerful viewing modes:
- **Workflow view** organizes merge requests by their review state, grouping work by its stage in the code review workflow.
- **Role view** groups your merge requests by whether you're the author or reviewer, giving you a clear separation of responsibilities.
The **Active** tab shows merge requests requiring attention, **Merged** displays recently completed work,
and **Search** provides comprehensive filtering capabilities.
The new homepage also expands your visibility by combining both authored and assigned merge requests,
ensuring you never miss work that's been delegated to you.
stage: create
self-managed: true
gitlab-com: true
available_in: [Free, Premium, Ultimate]
documentation_link: https://docs.gitlab.com/user/project/merge_requests/homepage/
image_url: https://about.gitlab.com/images/18_2/create-action-focused-mr-homepage.png
published_at: 2025-07-17
release: 18.2
- name: Improve security with immutable container tags
description: |
Container registries are critical infrastructure for modern DevSecOps teams.
However, even with protected container tags, organizations still face a challenge:
After a tag is created, users with sufficient permissions can alter it.
This creates risks for teams that rely on specific tagged versions of container images for production stability.
Any modification—even by authorized users—can introduce unintended changes or compromise deployment integrity.
With immutable container tags, you can protect container images from unintended changes.
After a tag is created that matches an immutable rule, no one can modify the container image.
You can now:
- Create up to 5 total protection rules per project (combining both protected and immutable rules) using RE2 regex patterns.
- Protect critical tags like latest, semantic versions (for example, v1.0.0), or release candidates from any modification.
- Ensure immutable tags are automatically excluded from cleanup policies.
Immutable container tags require the next-generation container registry, which is enabled by default on GitLab.com.
For GitLab Self-Managed instances, you must enable the [metadata database](https://docs.gitlab.com/administration/packages/container_registry_metadata_database/)
to use immutable container tags.
stage: package
self-managed: true
gitlab-com: true
available_in: [Ultimate]
documentation_link: https://docs.gitlab.com/user/packages/container_registry/immutable_container_tags/
image_url: https://about.gitlab.com/images/18_2/immutable_tags_18_1.png
published_at: 2025-07-17
release: 18.2

23
db/docs/snippet_user_mentions.yml
View File

@ -10,23 +10,6 @@ introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/19009
milestone: '12.6'
table_size: small
gitlab_schema: gitlab_main_cell
desired_sharding_key:
snippet_project_id:
references: projects
backfill_via:
parent:
foreign_key: snippet_id
table: snippets
sharding_key: project_id
belongs_to: snippet
snippet_organization_id:
references: organizations
backfill_via:
parent:
foreign_key: snippet_id
table: snippets
sharding_key: organization_id
belongs_to: snippet
desired_sharding_key_migration_job_name:
- BackfillSnippetUserMentionsSnippetProjectId
- BackfillSnippetUserMentionsSnippetOrganizationId
sharding_key:
snippet_project_id: projects
snippet_organization_id: organizations

16
db/post_migrate/20250714212858_add_multi_column_not_null_constraint_to_snippet_user_mentions.rb Normal file
View File

@ -0,0 +1,16 @@
# frozen_string_literal: true
class AddMultiColumnNotNullConstraintToSnippetUserMentions < Gitlab::Database::Migration[2.3]
milestone '18.3'
disable_ddl_transaction!
def up
add_multi_column_not_null_constraint(:snippet_user_mentions, :snippet_project_id,
:snippet_organization_id)
end
def down
remove_multi_column_not_null_constraint(:snippet_user_mentions, :snippet_project_id,
:snippet_organization_id)
end
end

1
db/schema_migrations/20250714212858 Normal file
View File

@ -0,0 +1 @@
b741bbf01151232fe0f061f9d6e344adc9bf100fd42bb19b25222b6b9a387087

3
db/structure.sql
View File

@ -23827,7 +23827,8 @@ CREATE TABLE snippet_user_mentions (
mentioned_groups_ids bigint[],
note_id bigint,
snippet_project_id bigint,
snippet_organization_id bigint
snippet_organization_id bigint,
CONSTRAINT check_25b8666c20 CHECK ((num_nonnulls(snippet_organization_id, snippet_project_id) = 1))
);
CREATE SEQUENCE snippet_user_mentions_id_seq

49
doc/user/application_security/policies/pipeline_execution_policies.md
View File

@ -303,55 +303,6 @@ To customize policy enforcement, you can define a policy's scope to either inclu
specified projects, groups, or compliance framework labels. For more details, see
[Scope](_index.md#scope).
## Pipeline execution policy limits
For performance reasons, GitLab limits the number of pipeline execution policies that can run as part of a security policy project or pipeline. By default, these are the maximum number of pipelines execution policies:
- Five per security policy project
- Five per pipeline
### Adjust policy limits
{{< history >}}
- [Configurable limits introduced](https://gitlab.com/groups/gitlab-org/-/epics/16929) in GitLab 17.11.
{{< /history >}}
The *Maximum 5 pipeline execution policies per security policy project* limit can be adjusted at different levels:
#### Adjust the limit for an instance
{{< details >}}
- Offering: GitLab Self-Managed
{{< /details >}}
On GitLab Self-Managed instances, administrators can adjust the limits for the entire instance, up to a maximum of 20 pipeline execution policies:
1. Go to **Admin Area** > **Settings** > **Security and compliance**.
1. Expand the **Security policies** section.
1. Set a new value for **Maximum number of pipeline execution policies allowed per security policy configuration**.
1. Select **Save changes**.
#### Adjust the limit for a top-level group
GitLab instance administrators can modify the limits for top-level groups. These group limits can exceed the configured or default instance limits.
{{< alert type="note" >}}
Increasing these limits can affect system performance, especially for complex policies or when applying many policies simultaneously.
{{< /alert >}}
To adjust the limit for a top-level group:
1. Go to **Admin Area** > **Overview** > **Groups**.
1. In the row of the top-level group you want to modify, select **Edit**.
1. Set a new value for **Maximum number of pipeline execution policies allowed per security policy configuration**.
1. Select **Save changes**.
When the limit for an individual group is set to zero, the system will fall back to using the instance-wide default value. This ensures that groups with a zero limit can still create pipeline execution policies according to the instance default configuration.
## Manage access to the CI/CD configuration
When you enforce pipeline execution policies on a project, users that trigger pipelines must have at least read-only access to the project that contains the policy CI/CD configuration. You can grant access to the project manually or automatically.

64
doc/user/application_security/policies/security_policy_projects.md
View File

@ -173,7 +173,69 @@ However, when you enforce a
All users who have access to the project policy page and are not project owners instead view a
button linking out to the associated security policy project.
## Deleting a security policy project
## Changing policy limits
{{< details >}}
- Offering: GitLab Self-Managed
{{< /details >}}
{{< history >}}
- [Configurable limits introduced](https://gitlab.com/groups/gitlab-org/-/epics/8084) in GitLab 18.3.
{{< /history >}}
For performance reasons, GitLab limits the number of policies that can be configured in a security policy project.
{{< alert type="warning" >}}
If you reduce the limit below the number of policies currently stored in a security policy project, GitLab does not enforce any policies after the limit. To re-enable the policies, increase the limit to match the number of policies in the largest security policy project.
{{< /alert >}}
The default limits are:
| Policy type | Default policy limit |
| --------------------------------- | ---------------------- |
| Merge request approval policies | 5 |
| Scan execution policies | 5 |
| Pipeline execution policies | 5 |
| Vulnerability management policies | 5 |
On GitLab Self-Managed instances, instance administrators can adjust the limits for the entire instance, up to a maximum of 20 of each type of policy.
Administrator can also change the limits for a specific top-level group.
### Change the policy limits for an instance
To change the maximum number of policies your organization can store in a security policy project:
1. Go to **Admin Area** > **Settings** > **Security and compliance**.
1. Expand the **Security policies** section.
1. For each type of policy you want to change, set a new value for **Maximum number of {policy type} allowed per security policy configuration**.
1. Select **Save changes**.
#### Change the policy limits for a top-level group
Group limits can exceed the configured or default instance limits. To change the maximum number of policies your organization can store in a security policy project for a top-level group:
{{< alert type="note" >}}
Increasing these limits can affect system performance, especially if you apply a large number of complex policies.
{{< /alert >}}
To adjust the limit for a top-level group:
1. Go to **Admin Area** > **Overview** > **Groups**.
1. In the row of the top-level group you want to modify, select **Edit**.
1. For each type of policy you want to change, set a new value for **Maximum number of {policy type} allowed per security policy configuration**.
1. Select **Save changes**.
If you set the limit for an individual group to `0`, the system uses the instance-wide default value. This ensures that groups with a zero limit can still create policies according to the default instance configuration.
## Delete a security policy project
{{< history >}}

4
doc/user/application_security/policies/vulnerability_management_policy_schema.md
View File

@ -6,9 +6,7 @@ title: Vulnerability management policy schema
---
The YAML file with vulnerability management policies consists of an array of objects matching
vulnerability management policy schema nested under the `vulnerability_management_policy` key. You
can configure a maximum of 5 policies under the `vulnerability_management_policy` key. Any other
policies configured after the first 5 are not applied.
the vulnerability management policy schema nested under the `vulnerability_management_policy` key.
When you save a vulnerability management policy, its content is validated against the vulnerability
management policy schema. If you're not familiar with how to read

19
lib/gitlab/current/organization.rb
View File

@ -3,15 +3,19 @@
module Gitlab
module Current
class Organization
attr_reader :params, :user
attr_reader :params, :user, :headers
def initialize(params: {}, user: nil)
SESSION_KEY = :organization_id
HTTP_HEADER = 'X-GitLab-Organization-ID'
def initialize(params: {}, headers: nil, user: nil)
@params = params
@user = user
@headers = headers
end
def organization
from_params || from_user || fallback_organization
from_params || from_headers || from_user || fallback_organization
end
private
@ -20,6 +24,15 @@ module Gitlab
from_group_params || from_organization_params
end
def from_headers
return unless headers.respond_to?(:[])
header_organization_id = headers[HTTP_HEADER]
return unless header_organization_id.to_i > 0
::Organizations::Organization.find_by_id(header_organization_id)
end
def from_user
return unless user

18
locale/gitlab.pot
View File

@ -38211,6 +38211,9 @@ msgstr ""
msgid "Maximum number of actions per scan execution policy"
msgstr ""
msgid "Maximum number of approval policies allowed per security policy configuration"
msgstr ""
msgid "Maximum number of changes (branches or tags) in a single push above which a bulk push event is created (default is 3). Setting to 0 does not disable throttling."
msgstr ""
@ -38250,6 +38253,9 @@ msgstr ""
msgid "Maximum number of requests per minute for each raw path (default is 300). Set to 0 to disable throttling."
msgstr ""
msgid "Maximum number of scan execution policies allowed per security policy configuration"
msgstr ""
msgid "Maximum number of schedule rules per scan execution policy"
msgstr ""
@ -38265,6 +38271,9 @@ msgstr ""
msgid "Maximum number of variables loaded (2000)"
msgstr ""
msgid "Maximum number of vulnerability management policies allowed per security policy configuration"
msgstr ""
msgid "Maximum of 255 characters"
msgstr ""
@ -63185,12 +63194,21 @@ msgstr ""
msgid "The maximum file size is %{size}."
msgstr ""
msgid "The maximum number of approval policies allowed per security policy configuration can exceed the limit for the instance. Set to 0 to use instance limit."
msgstr ""
msgid "The maximum number of pipeline execution policies allowed per security policy configuration can exceed the limit for the instance. Set to 0 to use instance limit."
msgstr ""
msgid "The maximum number of scan execution policies allowed per security policy configuration can exceed the limit for the instance. Set to 0 to use instance limit."
msgstr ""
msgid "The maximum number of tags that a single worker accepts for cleanup. If the number of tags goes above this limit, the list of tags to delete is truncated to this number. To remove this limit, set it to 0."
msgstr ""
msgid "The maximum number of vulnerability management policies allowed per security policy configuration can exceed the limit for the instance. Set to 0 to use instance limit."
msgstr ""
msgid "The merge checks are incomplete because the latest pipeline failed, the pipeline status cannot be verified, or the merge request target branch was changed. You should run a new pipeline before merging."
msgstr ""

2
package.json
View File

@ -65,7 +65,7 @@
"@gitlab/fonts": "^1.3.0",
"@gitlab/query-language-rust": "0.13.1",
"@gitlab/svgs": "3.141.0",
"@gitlab/ui": "115.5.0",
"@gitlab/ui": "115.6.0",
"@gitlab/vue-router-vue3": "npm:vue-router@4.5.1",
"@gitlab/vuex-vue3": "npm:vuex@4.1.0",
"@gitlab/web-ide": "^0.0.1-dev-20250704091020",

12
spec/controllers/application_controller_spec.rb
View File

@ -74,6 +74,18 @@ RSpec.describe ApplicationController, feature_category: :shared do
expect(Current.organization).to eq(current_organization)
end
context 'when X-GitLab-Organization-ID header is provided' do
let_it_be(:header_organization) { create(:organization) }
it 'sets the organization from header' do
request.headers['X-GitLab-Organization-ID'] = header_organization.id.to_s
get :index, format: :json
expect(Current.organization).to eq(header_organization)
end
end
context 'when multiple calls in one example are done' do
it 'does not update the organization' do
expect(Current).to receive(:organization=).once.and_call_original

113
spec/lib/gitlab/current/organization_spec.rb
View File

@ -8,60 +8,79 @@ RSpec.describe Gitlab::Current::Organization, feature_category: :organization do
let_it_be(:other_organization) { create(:organization) }
let_it_be(:organization) { create(:organization) }
let_it_be(:user_organization) { create(:organization) }
let_it_be(:header_organization) { create(:organization) }
let_it_be(:default_organization) { create(:organization, :default) }
let_it_be(:group) { create(:group, organization: organization) }
let_it_be(:user) { create(:user, organization_users: [create(:organization_user, organization: user_organization)]) }
let(:params_with_namespace_id) { { namespace_id: group.full_path } }
let(:params_with_group_id) { { group_id: group.full_path } }
let(:params_with_groups_id) { { controller: 'groups', id: group.full_path } }
let(:params_with_org_path) { { organization_path: other_organization.path } }
let(:params_with_empty_namespace) { { namespace_id: '' } }
let(:params_with_invalid_namespace) { { namespace_id: 'not_found' } }
let(:params_with_empty_org_path) { { organization_path: '' } }
let(:params_with_invalid_org_path) { { organization_path: 'not_found' } }
let(:params_with_invalid_groups_id) { { controller: 'groups', id: 'not_found' } }
let(:params_with_invalid_group_id) { { group_id: 'not_found' } }
let(:empty_params) { {} }
let_it_be(:params_with_namespace_id) { { namespace_id: group.full_path } }
let_it_be(:params_with_group_id) { { group_id: group.full_path } }
let_it_be(:params_with_groups_id) { { controller: 'groups', id: group.full_path } }
let_it_be(:params_with_org_path) { { organization_path: other_organization.path } }
let_it_be(:params_with_empty_namespace) { { namespace_id: '' } }
let_it_be(:params_with_invalid_namespace) { { namespace_id: 'not_found' } }
let_it_be(:params_with_empty_org_path) { { organization_path: '' } }
let_it_be(:params_with_invalid_org_path) { { organization_path: 'not_found' } }
let_it_be(:params_with_invalid_groups_id) { { controller: 'groups', id: 'not_found' } }
let_it_be(:params_with_invalid_group_id) { { group_id: 'not_found' } }
let_it_be(:empty_params) { {} }
let_it_be(:headers_with_valid_org) { { 'X-GitLab-Organization-ID' => header_organization.id.to_s } }
let_it_be(:headers_with_invalid_org) { { 'X-GitLab-Organization-ID' => non_existing_record_id.to_s } }
let_it_be(:headers_with_zero) { { 'X-GitLab-Organization-ID' => '0' } }
let_it_be(:headers_with_negative) { { 'X-GitLab-Organization-ID' => '-1' } }
let_it_be(:headers_with_non_numeric) { { 'X-GitLab-Organization-ID' => 'abc' } }
let_it_be(:empty_headers) { {} }
let_it_be(:nil_headers) { nil }
describe '#organization' do
subject(:current_organization) { described_class.new(params: params, user: user_param).organization }
where(:params, :user_param, :expected, :enables_fallback) do
# Valid params without user - should find organization from params
ref(:params_with_namespace_id) | nil | ref(:organization) | false
ref(:params_with_group_id) | nil | ref(:organization) | false
ref(:params_with_groups_id) | nil | ref(:organization) | false
ref(:params_with_org_path) | nil | ref(:other_organization) | false
# Valid params with user - params should take precedence over user
ref(:params_with_namespace_id) | ref(:user) | ref(:organization) | false
ref(:params_with_group_id) | ref(:user) | ref(:organization) | false
ref(:params_with_groups_id) | ref(:user) | ref(:organization) | false
ref(:params_with_org_path) | ref(:user) | ref(:other_organization) | false
# Params without user when organization is not found - should fall back to default
ref(:params_with_invalid_namespace) | nil | ref(:default_organization) | true
ref(:params_with_empty_namespace) | nil | ref(:default_organization) | true
ref(:params_with_empty_org_path) | nil | ref(:default_organization) | true
ref(:params_with_invalid_org_path) | nil | ref(:default_organization) | true
ref(:params_with_invalid_groups_id) | nil | ref(:default_organization) | true
ref(:params_with_invalid_group_id) | nil | ref(:default_organization) | true
# Invalid params with user - should fall back to user (params tried first but failed)
ref(:params_with_invalid_namespace) | ref(:user) | ref(:user_organization) | false
ref(:params_with_empty_namespace) | ref(:user) | ref(:user_organization) | false
ref(:params_with_invalid_org_path) | ref(:user) | ref(:user_organization) | false
ref(:params_with_invalid_groups_id) | ref(:user) | ref(:user_organization) | false
ref(:params_with_invalid_group_id) | ref(:user) | ref(:user_organization) | false
# No params with user - should find organization from user
ref(:empty_params) | ref(:user) | ref(:user_organization) | false
# No params without user - should fall back to default
ref(:empty_params) | nil | ref(:default_organization) | true
subject(:current_organization) do
described_class.new(params: params, user: user_param, headers: headers_param).organization
end
# rubocop:disable Layout/LineLength -- Parameterized table format requires long lines
where(:params, :headers_param, :user_param, :expected, :enables_fallback) do
# Valid params take precedence over everything
ref(:params_with_namespace_id) | ref(:headers_with_valid_org) | ref(:user) | ref(:organization) | false
ref(:params_with_group_id) | ref(:headers_with_valid_org) | ref(:user) | ref(:organization) | false
ref(:params_with_groups_id) | ref(:headers_with_valid_org) | ref(:user) | ref(:organization) | false
ref(:params_with_org_path) | ref(:headers_with_valid_org) | ref(:user) | ref(:other_organization) | false
# Valid params without headers or user
ref(:params_with_namespace_id) | ref(:empty_headers) | nil | ref(:organization) | false
ref(:params_with_group_id) | ref(:empty_headers) | nil | ref(:organization) | false
ref(:params_with_groups_id) | ref(:empty_headers) | nil | ref(:organization) | false
ref(:params_with_org_path) | ref(:empty_headers) | nil | ref(:other_organization) | false
# Invalid params fall back to headers, then user, then default
ref(:params_with_invalid_namespace) | ref(:headers_with_valid_org) | ref(:user) | ref(:header_organization) | false
ref(:params_with_invalid_namespace) | ref(:empty_headers) | ref(:user) | ref(:user_organization) | false
ref(:params_with_invalid_namespace) | ref(:headers_with_invalid_org) | ref(:user) | ref(:user_organization) | false
ref(:params_with_invalid_namespace) | ref(:empty_headers) | nil | ref(:default_organization) | true
ref(:params_with_invalid_namespace) | ref(:headers_with_invalid_org) | nil | ref(:default_organization) | true
# Empty params follow same fallback chain
ref(:empty_params) | ref(:headers_with_valid_org) | ref(:user) | ref(:header_organization) | false
ref(:empty_params) | ref(:empty_headers) | ref(:user) | ref(:user_organization) | false
ref(:empty_params) | ref(:nil_headers) | ref(:user) | ref(:user_organization) | false
ref(:empty_params) | ref(:headers_with_invalid_org) | ref(:user) | ref(:user_organization) | false
ref(:empty_params) | ref(:empty_headers) | nil | ref(:default_organization) | true
ref(:empty_params) | ref(:nil_headers) | nil | ref(:default_organization) | true
ref(:empty_params) | ref(:headers_with_invalid_org) | nil | ref(:default_organization) | true
# Test header regex validation - invalid formats should fall back to user/default
ref(:empty_params) | ref(:headers_with_zero) | ref(:user) | ref(:user_organization) | false
ref(:empty_params) | ref(:headers_with_negative) | ref(:user) | ref(:user_organization) | false
ref(:empty_params) | ref(:headers_with_non_numeric) | ref(:user) | ref(:user_organization) | false
ref(:empty_params) | ref(:headers_with_zero) | nil | ref(:default_organization) | true
# Test other invalid parameter types to ensure consistent fallback behavior
ref(:params_with_empty_namespace) | ref(:empty_headers) | nil | ref(:default_organization) | true
ref(:params_with_invalid_groups_id) | ref(:headers_with_valid_org) | ref(:user) | ref(:header_organization) | false
ref(:params_with_invalid_org_path) | ref(:headers_with_valid_org) | ref(:user) | ref(:header_organization) | false
ref(:params_with_invalid_org_path) | ref(:headers_with_invalid_org) | ref(:user) | ref(:user_organization) | false
ref(:params_with_invalid_group_id) | ref(:headers_with_invalid_org) | nil | ref(:default_organization) | true
end
# rubocop:enable Layout/LineLength
with_them do
it { is_expected.to eq(expected) }

8
yarn.lock
View File

@ -1449,10 +1449,10 @@
resolved "https://registry.yarnpkg.com/@gitlab/svgs/-/svgs-3.141.0.tgz#0be316b5dfdcbac0796c9b71b941740bccb89ec6"
integrity sha512-xLrEY14dc1jGknP4tZ5SgrGojDsmkI7S2sii83MBqwdqy9QQ3DWxdreeClQkBDXC/A6wDTbJAN0U4ebGBX7Y7w==
"@gitlab/ui@115.5.0":
version "115.5.0"
resolved "https://registry.yarnpkg.com/@gitlab/ui/-/ui-115.5.0.tgz#88100a1dc152bf4bb045293c5faf12f1ae7c8c15"
integrity sha512-CGDQogwLATAvtBqUcECSnJiNUBvipAMKl1UhSF2JBDVYJ1etYjFaLSb6lho0MM7iaTL95LKGhoQf+lhwprywZw==
"@gitlab/ui@115.6.0":
version "115.6.0"
resolved "https://registry.yarnpkg.com/@gitlab/ui/-/ui-115.6.0.tgz#9a43ac939c9d09984bf37b54c68d2444ba03b6f7"
integrity sha512-YEYk2ySGKwTSfzGAiODLYYaOrSEc7LnotEGMdpfd8fQfoYESem/EO7IrAI7k7JOpouM99V17B1stWh9XPbYPSw==
dependencies:
"@floating-ui/dom" "1.7.2"
echarts "^5.6.0"