docs: note cluster scoping changes in 2.12x (cherry-pick #19684)

docs/operator-manual/upgrading/2.11-2.12.md

@@ -1,5 +1,18 @@
 # v2.11 to 2.12
 
+## Cluster secret scoping changes
+
+From Argo CD 2.12, there have been some changes to the use of cluster secrets where a `project` is a non-empty value. 
+Previously, an `Application` or `ApplicationSet` would use any cluster secret matching the URL of the `repoUrl` field. 
+From 2.12, we now check to see whether the project field of an application _also_ matches the project field of the cluster 
+secret. What this means is that if you have a cluster secret scoped to `project-a`, an application scoped to `project-b`
+can no longer make use of the secret. If you have a cluster secret that's intended to be used by applications in multiple 
+projects, you need to **unset** the `project` field.
+
+This also applies when using the Git generator in applicationsets; since an applicationset is not scoped to a particular
+project any cluster secrets it makes use of also needs to be globally scoped (i.e. any secret needs to have an unset 
+`project`).
+
 ## Upgraded Helm Version
 
 Note that bundled Helm version has been upgraded from 3.14.4 to 3.15.2.

docs/user-guide/projects.md

@@ -319,6 +319,11 @@ stringData:
   password: ****
 ```
 
+!!! warning
+Please keep in mind when using a project-scoped repository, only applications from the same project can make use of
+it. When using applicationsets with the Git generator, only non-scoped repositories can be used (i.e. repositories that
+do _not_ have a `project` set).
+
 All the examples above talk about Git repositories, but the same principles apply to clusters as well.
 
 ```yaml