Add latest changes from gitlab-org/gitlab@master

6 files changed, 50 insertions, 71 deletions

diff --git a/doc/administration/audit_events.md b/doc/administration/audit_events.md
index 0aa0d163972..d10c1616eaf 100644
--- a/doc/administration/audit_events.md
+++ b/doc/administration/audit_events.md
@@ -21,17 +21,46 @@ NOTE:
 You can't configure a retention policy for audit events, but epic
 [7917](https://gitlab.com/groups/gitlab-org/-/epics/7917) proposes to change this.
 
-## List of events
+## View audit events
 
-There are two kinds of events logged:
+Depending on the events you want to view, at a minimum you must have:
 
-- Events scoped to the group or project, used by group and project managers
-  to look up who made a change.
-- Instance events scoped to the whole GitLab instance, used by your Compliance team to
-  perform formal audits.
+- For group audit events of all users in the group, the Owner role for the group.
+- For project audit events of all users in the project, the Maintainer role for the project.
+- For group and project audit events based on your own actions, the Developer role for the group or project.
+- [Auditor users](auditor_users.md) can see group and project events for all users.
 
-NOTE:
-Some events are recorded and available only as [streaming audit events](audit_event_streaming.md).
+You can view audit events scoped to a group or project.
+
+To view a group's audit events:
+
+1. Go to the group.
+1. On the left sidebar, select **Security & Compliance > Audit Events**.
+
+Group events do not include project audit events. Group events can also be accessed using the
+[Group Audit Events API](../api/audit_events.md#group-audit-events). Group event queries are limited to a maximum of 30
+days.
+
+To view a project's audit events:
+
+1. Go to the project.
+1. On the left sidebar, select **Security & Compliance > Audit Events**.
+
+Project events can also be accessed using the [Project Audit Events API](../api/audit_events.md#project-audit-events).
+Project event queries are limited to a maximum of 30 days.
+
+### View instance audit events **(PREMIUM SELF)**
+
+You can view audit events from user actions across an entire GitLab instance.
+
+To view instance audit events:
+
+1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, select **Monitoring > Audit Events**.
+
+## List of events
+
+You can view different events depending on the version of GitLab you have.
 
 ### Impersonation data
 
@@ -51,19 +80,7 @@ When a user is being [impersonated](../user/admin_area/index.md#user-impersonati
 
 ### Group events
 
-A user with:
-
-- Owner role (or above) can retrieve group audit events of all users.
-- Developer or Maintainer role is limited to group audit events based on their individual actions.
-
-Group events do not include project audit events.
-
-To view a group's audit events:
-
-1. Go to the group.
-1. On the left sidebar, select **Security & Compliance > Audit Events**.
-
-From there, you can see the following actions:
+The following actions on groups generate group audit events:
 
 - Group name or path changed.
 - Group repository size limit changed.
@@ -111,19 +128,9 @@ From there, you can see the following actions:
 - Changes to streaming audit destination custom HTTP headers. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/366350) in GitLab 15.3.
 - Group had a security policy project linked, changed, or unlinked. ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/377877) in GitLab 15.6)
 
-Group events can also be accessed via the [Group Audit Events API](../api/audit_events.md#group-audit-events)
-
 ### Project events
 
-A user with a Maintainer role (or above) can retrieve project audit events of all users.
-A user with a Developer role is limited to project audit events based on their individual actions.
-
-To view a project's audit events:
-
-1. Go to the project.
-1. On the left sidebar, select **Security & Compliance > Audit Events**.
-
-From there, you can see the following actions:
+The following actions on projects generate project audit events:
 
 - Added or removed deploy keys
 - Project created, deleted, renamed, moved (transferred), changed path
@@ -182,24 +189,9 @@ From there, you can see the following actions:
 - Project was scheduled for deletion due to inactivity ([introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/85689) in GitLab 15.0)
 - Project had a security policy project linked, changed, or unlinked ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/377877) in GitLab 15.6)
 
-Project events can also be accessed via the [Project Audit Events API](../api/audit_events.md#project-audit-events).
-
-Project event queries are limited to a maximum of 30 days.
-
 ### Instance events **(PREMIUM SELF)**
 
-Server-wide audit events introduce the ability to observe user actions across
-the entire instance of your GitLab server, making it easy to understand who
-changed what and when for audit purposes.
-
-Instance events do not include group or project audit events.
-
-To view the server-wide audit events:
-
-1. On the top bar, select **Main menu > Admin**.
-1. On the left sidebar, select **Monitoring > Audit Events**.
-
-The following user actions are recorded:
+The following user actions on a GitLab instance generate instance audit events:
 
 - Sign-in events and the authentication type (such as standard, LDAP, or OmniAuth)
 - Failed sign-ins
diff --git a/doc/architecture/blueprints/ci_pipeline_components/index.md b/doc/architecture/blueprints/ci_pipeline_components/index.md
index e8fbc15a376..f98a82dfe5b 100644
--- a/doc/architecture/blueprints/ci_pipeline_components/index.md
+++ b/doc/architecture/blueprints/ci_pipeline_components/index.md
@@ -3,7 +3,7 @@ status: proposed
 creation-date: "2022-09-14"
 authors: [ "@fabio", "@grzesiek" ]
 coach: "@kamil"
-approvers: [ "@dov" ]
+approvers: [ "@dhershkovitch" ]
 owning-stage: "~devops::verify"
 participating-stages: []
 ---
diff --git a/doc/development/caching.md b/doc/development/caching.md
index 36fbfc7010e..4c91e8eba6e 100644
--- a/doc/development/caching.md
+++ b/doc/development/caching.md
@@ -166,7 +166,7 @@ Is the cache being added "worthy"? This can be hard to measure, but you can cons
    - Calling the same method multiple times but only calculating the value once.
    - Stored in Ruby memory.
    - `@article ||= Article.find(params[:id])`
-   - `strong_memoize { Article.find(params[:id]) }`
+   - `strong_memoize_attr :method_name`
 1. Request caching:
    - Return the same value for a key for the duration of a web request.
    - `Gitlab::SafeRequestStore.fetch`
@@ -252,7 +252,7 @@ All the time!
 
 ### When to use method caching
 
-- Using instance variables, or [strong_memoize](utilities.md#strongmemoize) is something we all tend to do anyway.
+- Use instance variables, or [`StrongMemoize`](utilities.md#strongmemoize).
 - Useful when the same value is needed multiple times in a request.
 - Can be used to prevent multiple cache calls for the same key.
 - Can cause issues with ActiveRecord objects where a value doesn't change until you call
diff --git a/doc/development/secure_coding_guidelines.md b/doc/development/secure_coding_guidelines.md
index e99926663dd..0dc950cbc4c 100644
--- a/doc/development/secure_coding_guidelines.md
+++ b/doc/development/secure_coding_guidelines.md
@@ -718,13 +718,12 @@ There are some cases where `users` passed in the code is actually referring to a
 
 ```ruby
       def find_user_from_sources
-        strong_memoize(:find_user_from_sources) do
-          deploy_token_from_request ||
-            find_user_from_bearer_token ||
-            find_user_from_job_token ||
-            user_from_warden
-        end
+        deploy_token_from_request ||
+          find_user_from_bearer_token ||
+          find_user_from_job_token ||
+          user_from_warden
       end
+      strong_memoize_attr :find_user_from_sources
 ```
 
 ### Past Vulnerable Code
diff --git a/doc/development/utilities.md b/doc/development/utilities.md
index 551834670b3..a7f0500fd71 100644
--- a/doc/development/utilities.md
+++ b/doc/development/utilities.md
@@ -181,20 +181,6 @@ Refer to [`strong_memoize.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/maste
     include Gitlab::Utils::StrongMemoize
 
     def result
-      strong_memoize(:result) do
-        search
-      end
-    end
-  end
-  ```
-
-  Alternatively, use the `strong_memoize_attr` helper to memoize the method for you:
-
-  ```ruby
-  class Find
-    include Gitlab::Utils::StrongMemoize
-
-    def result
       search
     end
     strong_memoize_attr :result
diff --git a/doc/update/index.md b/doc/update/index.md
index e810c63a7ea..31df17c4138 100644
--- a/doc/update/index.md
+++ b/doc/update/index.md
@@ -565,6 +565,8 @@ and [Helm Chart deployments](https://docs.gitlab.com/charts/). They come with ap
   than `<custom_hooks_dir>/<hook_name>`.
 - [Incorrect deletion of object storage files on Geo secondary sites](https://gitlab.com/gitlab-org/gitlab/-/issues/371397) can occur in certain situations. See [Geo: Incorrect object storage LFS file deletion on secondary site issue in GitLab 15.0.0 to 15.3.2](#geo-incorrect-object-storage-lfs-file-deletion-on-secondary-sites-in-gitlab-1500-to-1532).
 - The `FF_GITLAB_REGISTRY_HELPER_IMAGE` [feature flag](../administration/feature_flags.md#enable-or-disable-the-feature) is removed and helper images are always pulled from GitLab Registry.
+- The `AES256-GCM-SHA384` SSL cipher is no longer allowed by NGINX.
+  See how you can [add the cipher back](https://docs.gitlab.com/omnibus/update/gitlab_15_changes.html#aes256-gcm-sha384-ssl-cipher-no-longer-allowed-by-default-by-nginx) to the allow list.
 
 ### 14.10.0