Changes look good to me thanks @akashpaudel. Approving the same. I think we have all required approval, i will set the MR for MWPS

What does this MR do and why?

Fix Lint/UnusedMethodArgument offenses

In this MR I have applied rubocop autocorrect fix to Lint/UnusedMethodArgument offense in all the controller files in location app/controller

Command: bundle exec rubocop -A app/controllers/

Issue: #239356

References

#239356

Screenshots or screen recordings

How to set up and validate locally

Run command bundle exec rubocop -A app/controllers/ and you will get response no offenses detected

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #239356

@10io Can we also query plan for this query mentioned in MR description?

@alipniagov Finally I could wrap up the MR for removing service_accounts from features.rb and cleaning up the service_accounts_available_on_free_or_unlicensed feature flag.

I had to perform both operations in the same MR: once we remove service_accounts from the features file, the FF becomes unused — and an unused FF causes a cop failure — so both changes had to land together. That considerably increased the scope. Here's a guide to make review easier.

Review guide

This MR touches 55 files, but the actual logic change is small — most files are spec cleanups.

1. Core logic (2 files — start here)

• ee/app/models/gitlab_subscriptions/features.rb — one-line removal of :service_accounts from PREMIUM_FEATURES
• ee/lib/authn/service_accounts.rb — full rewrite: removes license gate, replaces with subscription/license plan checks. Free tier (SM: no premium/ultimate license; SaaS: no active paid subscription) gets a 100-seat cap. Paid tier is unlimited. Trial cap is also 100 unless allow_unlimited_service_account_for_trials FF is on.

2. FF definition deleted (1 file)

• config/feature_flags/gitlab_com_derisk/service_accounts_available_on_free_or_unlicensed.yml — deleted. Was a workaround for free-tier SaaS access; no longer needed now that service accounts are unconditionally available.

3. Spec changes (~52 files — mechanical)

All spec changes fall into one of these patterns:

a) Remove stub_licensed_features(service_accounts: ...) calls These now raise ArgumentError since :service_accounts is no longer a licensed feature. Affects policies/, requests/, controllers/, services/, models/, lib/ specs.

b) Add free_tier? / free_tier_namespace? mocks Tests that verify service_access_tokens_expiration_enforced behaviour (PAT expiry for service accounts) now stub Authn::ServiceAccounts.free_tier? or free_tier_namespace? to false to simulate a paid-tier environment. Without this, test environments (no license/subscription) would always enforce expiry and break those table-driven tests.

c) Update "Starter plan raises error" tests users/service_accounts/create_service_spec.rb and namespaces/service_accounts/create_service_spec.rb had tests expecting an error for Starter plan licenses. Starter plan is now treated as free tier (allowed up to 100 seats), so these now expect success.

d) Navbar context spec/support/shared_contexts/navbar_structure_context.rb updated to include Service accounts in Settings for group-owned projects (now always accessible, not license-gated).

What stays the same

• Free tier seat cap (100) still enforced
• Mandatory PAT expiry for free-tier service accounts still enforced
• Trial seat cap and allow_unlimited_service_account_for_trials FF preserved

Let me know what you think!

@eduardosanz I am not sure I understand you here. For me the above link is redirecting to https://gitlab.com/-/user_settings/personal_access_tokens?state=active&sort=expires_asc

What does this MR do and why?

Add Gettext/PascalCaseNamespace RuboCop cop

Adds a new cop that detects s_() and n_() calls where the namespace contains characters other than [a-zA-Z0-9]. Namespaces must be PascalCase alphanumeric only; underscores, spaces, and other non-alphanumeric characters are not allowed.

A namespace is defined as a sequence of word characters and spaces at the start of the string, ending with a non-space character immediately before |. This avoids false positives on strings like s_('Hello | World') which have a space before |.

1. First commit: introduction of the rule.
2. Second commit: manually change a few non-conforming namespaces.

Documentation: https://docs.gitlab.com/development/i18n/externalization/#namespaces

References

Related to:

• !226764
• !226732
• !227272

Screenshots or screen recordings

N/A

How to set up and validate locally

N/A

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Thanks @eduardosanz, I addressed all suggestions, please take another look.

@atevans Could you also please check this MR? This is a small change

Smriti Garg (edb116a5) at 19 Mar 15:22

Smriti Garg (2f6b008c) at 19 Mar 15:15

What does this MR do and why?

Redirect users to legacy PAT create page if name & scopes exist in URL

• Previously we were only redirecting users to the create personal access token form if the name of the token was GitLab Workflow Extension, !222776
• We noticed from the logs that users were using other names but weren't being redirected
• Hence, redirect users if any name and scopes are present

References

Screenshots or screen recordings

How to set up and validate locally

1. Enable feature flag from the rails console:

Feature.enable(:granular_personal_access_tokens)

2. Log-in as any user and navigate to /-/user_settings/personal_access_tokens?name=Test&scopes=api
3. You should be redirected to create a personal access token

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

I suppose its only name and scope presence in params that needs to be checked here.

Thanks @eduardosanz

Thanks for the change @eduardosanz . it looks good to me, just one query for your consideration

Question Should we get this change reviewed from somebody in documentation?

@alan Thanks for this update. Query looks fine to me. I am approving for database. Will pass it on to database maintainer for a further look

What does this MR do and why?

Adds a new PEP/SEP-scoped mergeability check (security_policy_pipeline_check) that ensures all pipelines for the latest commit must succeed before a merge request can be merged when security policies are enforced.

Problem

When Pipeline Execution Policies (PEP) or Scan Execution Policies (SEP) inject security scans into MR pipelines, projects with existing branch pipelines end up with duplicate pipelines. The existing mergeability check only evaluates the MR pipeline (which includes the security scans), completely ignoring the branch pipeline where functional tests may be failing. This allows broken code to be merged even when branch pipelines are red.

Solution

Introduces a new CheckSecurityPolicyPipelineStatusService mergeability check that:

• Activates only when the project has security_orchestration_policies license, has PEP/SEP policy configurations (scoped to type_scan_execution_policy or type_pipeline_execution_policy to avoid activating for projects with only approval or vulnerability management policies), and at least one internal pipeline exists for the latest MR commit
• Excludes external pipelines (created via the Commit Status API) to prevent bypassing the security policy check by setting a commit status to success (see #535437)
• Evaluates both the latest MR pipeline (merge_request_event source) and the latest branch pipeline (all other sources) for the HEAD SHA
• Supports merged results pipelines by using for_sha_or_source_sha to match pipelines where the SHA is a merge commit but source_sha is the branch HEAD
• Blocks or warns based on the project's "Pipelines must succeed" setting:
  • Setting enabled: hard block (failure) if any evaluated pipeline fails
  • Setting disabled: soft warning if any evaluated pipeline fails, user can still merge
• Respects the "Skipped pipelines are considered successful" setting (allow_merge_on_skipped_pipeline), consistent with CheckCiStatusService
• Waits (returns checking) if any evaluated pipeline is still active
• Is non-cacheable since pipeline statuses change dynamically
• Is skipped during auto-merge flows via skip_security_policy_pipeline_check
• Is gated behind a feature flag security_policy_pipeline_check (disabled by default)

Changes

• New service: ee/app/services/merge_requests/mergeability/check_security_policy_pipeline_status_service.rb - core mergeability check logic
• New scope: with_security_policy_jobs on Ci::Pipeline to efficiently query pipelines that have policy-injected builds
• MR model: registers the new check in mergeable_state_checks and adds skip_security_policy_pipeline_check to auto-merge skip options
• GraphQL: new SECURITY_POLICY_PIPELINE_CHECK enum value in DetailedMergeStatusEnum and MergeabilityCheckIdentifier
• Feature flag: security_policy_pipeline_check (gitlab_com_derisk, disabled by default)
• Docs & schema: updated GraphQL reference docs and introspection JSON

Note: Frontend changes (merge check component, contextual pipeline note, CSS, and frontend constants) have been removed from this MR and will be handled separately.

References

Closes #589650

How to set up and validate locally

1. Enable the security_orchestration_policies license feature
2. Enable the security_policy_pipeline_check feature flag
3. Create a project with a PEP or SEP policy configuration
4. Open a merge request and trigger a pipeline that has policy-injected jobs
5. Observe the new SECURITY_POLICY_PIPELINE_CHECK mergeability check identifier via the GraphQL API
6. Verify that a failing branch pipeline blocks (or warns on) the merge, even when the MR pipeline succeeds

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Thanks for the change @alipniagov . It LGTM. Approving ✔️

What does this MR do and why?

Removes the rate_limit_service_accounts_create feature flag, making rate limiting for service account creation unconditional across all API endpoints (instance, project, and group level).

This flag was introduced in 18.10 and has been fully rolled out on GitLab.com.

Note: This MR should be merged only after the 18.10 RC has been packaged.

Related to: https://gitlab.com/gitlab-org/gitlab/-/work_items/589751

Changes

• Deleted the feature flag YAML definition (config/feature_flags/gitlab_com_derisk/rate_limit_service_accounts_create.yml)
• Removed Feature.enabled?(:rate_limit_service_accounts_create) conditionals in:
  • ee/lib/api/service_accounts.rb
  • ee/lib/api/project_service_accounts.rb
  • ee/lib/api/group_service_accounts.rb
• Removed "flag disabled" test contexts in corresponding spec files (the it_behaves_like 'rate limited endpoint' shared examples remain to test the now-unconditional rate limiting)

MR acceptance checklist

• This MR is a feature flag cleanup (no new functionality)
• Tests remain to verify rate limiting behavior