Add latest changes from gitlab-org/gitlab@master

.gitlab/issue_templates/Security developer workflow.md

@@ -73,7 +73,7 @@ After your merge request has been approved according to our [approval guidelines
 | Date detected                       | YYYY-MM-DD | #TODO for AppSec - please follow the format               |
 | GitLab EE only                      | Yes/No     |                                                           |
 | Upgrade notes                       |            |                                                           |
-| GitLab Settings updated             | Yes/No     |                                                           |
+| Creates, updates or removes GitLab settings?             | Yes/No     |                                                           |
 | Migration required                  | Yes/No     |                                                           |
 | Breaking change to UI or public API | Yes/No     | <!-- How should the breaking change be communicated? -->  |
 | Thanks                              |            |                                                           |

app/assets/javascripts/access_level/constants.js

@@ -103,7 +103,7 @@ export const BASE_ROLES = [
     accessLevel: ACCESS_LEVEL_OWNER_INTEGER,
     occupiesSeat: true,
     description: s__(
-      'MemberRole|The Owner role is normally assigned to the individual or team responsible for managing and maintaining the group or creating the project. This role has the highest level of administrative control, and can manage all aspects of the group or project, including managing other Owners.',
+      'MemberRole|The Owner role is typically assigned to the individual or team responsible for managing and maintaining the group or creating the project. This role has the highest level of administrative control, and can manage all aspects of the group or project, including managing other Owners.',
     ),
   },
 ];

app/models/todo.rb

@@ -57,7 +57,7 @@ class Todo < ApplicationRecord
     else
       self
     end
-  }, polymorphic: true, touch: true # rubocop:disable Cop/PolymorphicAssociations
+  }, polymorphic: true # rubocop:disable Cop/PolymorphicAssociations
 
   belongs_to :user
   belongs_to :issue, -> { where("target_type = 'Issue'") }, foreign_key: :target_id

config/feature_flags/gitlab_com_derisk/auto_merge_train_elaborate_abort_msg.yml

@@ -1,9 +0,0 @@
----
-name: auto_merge_train_elaborate_abort_msg
-feature_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/467300
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/165581
-rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/500079
-milestone: '17.6'
-group: group::pipeline execution
-type: gitlab_com_derisk
-default_enabled: false

doc/administration/geo/secondary_proxy/index.md

@@ -89,7 +89,7 @@ routing configurations. To create a traffic policy:
    1. Select **Connect to**, then select **New endpoint**.
    1. Choose **Type** `value` and fill it in with `<your **secondary** IP address>`.
 
-   ![Add traffic policy endpoints](img/single_url_add_traffic_policy_endpoints_v14_5.png)
+   ![Route53 traffic policy editor showing a geolocation rule with two locations - Default and Europe - each connected to endpoints with different IP addresses](img/single_url_add_traffic_policy_endpoints_v14_5.png)
 
 1. Select **Create traffic policy**.
 1. Fill in **Policy record DNS name** with `gitlab`.

doc/administration/gitaly/configure_gitaly.md

@@ -887,7 +887,7 @@ SSHUploadPack Gitaly RPCs. Gitaly runs PostUploadPack when a
 user does a Git fetch by using HTTP, or SSHUploadPack when a
 user does a Git fetch by using SSH.
 When the cache is enabled, anything that uses PostUploadPack or SSHUploadPack can
-benefit from it. It is orthogonal to:
+benefit from it. It is independent of and unaffected by:
 
 - The transport (HTTP or SSH).
 - Git protocol version (v0 or v2).
@@ -934,11 +934,9 @@ In `/etc/gitlab/gitlab.rb`, set:
 gitaly['configuration'] = {
   # ...
   pack_objects_cache: {
-    # ...
     enabled: true,
-    # dir: '/var/opt/gitlab/git-data/repositories/+gitaly/PackObjectsCache',
-    # max_age: '5m',
-    # min_occurrences: 1,
+    # The default settings for "dir", "max_age" and "min_occurences" should be fine.
+    # If you want to customize these, see details below.
   },
 }
 ```
@@ -961,6 +959,10 @@ should be:
 - On a disk with enough IO bandwidth. If the cache disk runs out of IO bandwidth, all
   fetches, and probably the entire server, slows down.
 
+WARNING:
+All existing data in the specified directory will be removed. 
+Take care not to use a directory with existing data.
+
 By default, the cache storage directory is set to a subdirectory of the first Gitaly storage
 defined in the configuration file.
 

doc/administration/monitoring/health_check.md

@@ -16,7 +16,7 @@ database connection, Redis connection, and access to the file system. These
 endpoints [can be provided to schedulers like Kubernetes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) to hold
 traffic until the system is ready or restart the container as needed.
 
-Health check endpoints are normally used for load balancers
+Health check endpoints are typically used for load balancers
 and other Kubernetes scheduling systems that need to determine
 service availability before redirecting traffic.
 

doc/api/graphql/reference/index.md

@@ -40912,7 +40912,7 @@ Access level of a group or project member.
 | <a id="memberaccesslevelguest"></a>`GUEST` | The Guest role is for users who need visibility into a project or group but should not have the ability to make changes, such as external stakeholders. |
 | <a id="memberaccesslevelmaintainer"></a>`MAINTAINER` | The Maintainer role is primarily used for managing code reviews, approvals, and administrative settings for projects. This role can also manage project memberships. |
 | <a id="memberaccesslevelminimal_access"></a>`MINIMAL_ACCESS` | The Minimal Access role is for users who need the least amount of access into groups and projects. You can assign this role as a default, before giving a user another role with more permissions. |
-| <a id="memberaccesslevelowner"></a>`OWNER` | The Owner role is normally assigned to the individual or team responsible for managing and maintaining the group or creating the project. This role has the highest level of administrative control, and can manage all aspects of the group or project, including managing other Owners. |
+| <a id="memberaccesslevelowner"></a>`OWNER` | The Owner role is typically assigned to the individual or team responsible for managing and maintaining the group or creating the project. This role has the highest level of administrative control, and can manage all aspects of the group or project, including managing other Owners. |
 | <a id="memberaccesslevelplanner"></a>`PLANNER` | The Planner role is suitable for team members who need to manage projects and track work items but do not need to contribute code. |
 | <a id="memberaccesslevelreporter"></a>`REPORTER` | The Reporter role is suitable for team members who need to stay informed about a project or group but do not actively contribute code. |
 

doc/development/documentation/styleguide/word_list.md

@@ -533,14 +533,23 @@ Examples:
 - Use code generation to create code based on your comments.
 - Adjust your code generation results by adding code comments to your file.
 
-## Code Owner, `CODEOWNER`
+## Code Owner, code owner, `CODEOWNER`
 
-Use **Code Owner** for:
+Use **Code Owners** to refer to the feature name or concept. For example:
 
-- A person or group responsible for specific parts of your project's codebase.
-- The feature that defines the responsible person or group.
+- Use the Code Owners approval rules to protect your code.
 
-Use `CODEOWNER` for the filename that define ownership rules.
+Use **code owner** or **code owners**, lowercase, to refer to a person or group with code ownership responsibilities.
+For example:
+
+- Assign a code owner to the project.
+- Contact the code owner for a review.
+
+Do not use **codeowner**, **CodeOwner**, or **code-owner**.
+
+Use `CODEOWNERS`, uppercase and in backticks, to refer to the filename. For example:
+
+- Edit the `CODEOWNERS` file to define the code ownership rules.
 
 ## Code Review Summary
 

doc/operations/incident_management/alerts.md

@@ -41,7 +41,7 @@ The alert list displays the following information:
 
 Each level of alert contains a uniquely shaped and color-coded icon to help you identify the severity of a particular alert. These severity icons help you immediately identify which alerts you should prioritize investigating:
 
-![Alert Management Severity System](img/alert_management_severity_v13_0.png)
+![Alert severity icons showing different colors and shapes for critical, high, medium, low, info, and unknown levels](img/alert_management_severity_v13_0.png)
 
 Alerts contain one of the following icons:
 

lib/gitlab/access.rb

@@ -74,7 +74,7 @@ module Gitlab
           REPORTER => s_('MemberRole|The Reporter role is suitable for team members who need to stay informed about a project or group but do not actively contribute code.'),
           DEVELOPER => s_('MemberRole|The Developer role gives users access to contribute code while restricting sensitive administrative actions.'),
           MAINTAINER => s_('MemberRole|The Maintainer role is primarily used for managing code reviews, approvals, and administrative settings for projects. This role can also manage project memberships.'),
-          OWNER => s_('MemberRole|The Owner role is normally assigned to the individual or team responsible for managing and maintaining the group or creating the project. This role has the highest level of administrative control, and can manage all aspects of the group or project, including managing other Owners.')
+          OWNER => s_('MemberRole|The Owner role is typically assigned to the individual or team responsible for managing and maintaining the group or creating the project. This role has the highest level of administrative control, and can manage all aspects of the group or project, including managing other Owners.')
         }
       end
 

locale/gitlab.pot

@@ -34881,7 +34881,7 @@ msgstr ""
 msgid "MemberRole|The None role is assigned to the invited group users of a shared project when project sharing is disabled in group setting."
 msgstr ""
 
-msgid "MemberRole|The Owner role is normally assigned to the individual or team responsible for managing and maintaining the group or creating the project. This role has the highest level of administrative control, and can manage all aspects of the group or project, including managing other Owners."
+msgid "MemberRole|The Owner role is typically assigned to the individual or team responsible for managing and maintaining the group or creating the project. This role has the highest level of administrative control, and can manage all aspects of the group or project, including managing other Owners."
 msgstr ""
 
 msgid "MemberRole|The Planner role is a hybrid of the existing Guest and Reporter roles but designed for users who need access to planning workflows."

spec/frontend/members/mock_data.js

@@ -17,7 +17,7 @@ export const member = {
     integerValue: 50,
     stringValue: 'Owner',
     description:
-      'The Owner role is normally assigned to the individual or team responsible for managing and maintaining the group or creating the project. This role has the highest level of administrative control, and can manage all aspects of the group or project, including managing other Owners.',
+      'The Owner role is typically assigned to the individual or team responsible for managing and maintaining the group or creating the project. This role has the highest level of administrative control, and can manage all aspects of the group or project, including managing other Owners.',
   },
   source: {
     id: 178,

spec/models/todo_spec.rb

@@ -10,7 +10,7 @@ RSpec.describe Todo, feature_category: :notifications do
     it { is_expected.to belong_to(:note) }
     it { is_expected.to belong_to(:project) }
     it { is_expected.to belong_to(:group) }
-    it { is_expected.to belong_to(:target).touch(true) }
+    it { is_expected.to belong_to(:target).touch(false) }
     it { is_expected.to belong_to(:user) }
   end