Add latest changes from gitlab-org/gitlab@master

6 files changed, 27 insertions, 142 deletions

diff --git a/doc/api/geo_nodes.md b/doc/api/geo_nodes.md
index 1445e9768c1..b9d4f93d841 100644
--- a/doc/api/geo_nodes.md
+++ b/doc/api/geo_nodes.md
@@ -192,8 +192,6 @@ Example response:
 
 Updates settings of an existing Geo node.
 
-_This can only be run against a primary Geo node._
-
 ```plaintext
 PUT /geo_nodes/:id
 ```
diff --git a/doc/api/geo_sites.md b/doc/api/geo_sites.md
index 40410cdf540..ff06f668514 100644
--- a/doc/api/geo_sites.md
+++ b/doc/api/geo_sites.md
@@ -179,9 +179,9 @@ Example response:
 }
 ```
 
-## Edit a primary Geo site
+## Edit a Geo site
 
-Updates settings of an existing primary Geo site.
+Updates settings of an existing Geo site.
 
 ```plaintext
 PUT /geo_sites/:id
diff --git a/doc/ci/large_repositories/index.md b/doc/ci/large_repositories/index.md
index f728e9b9e17..4b17f3354aa 100644
--- a/doc/ci/large_repositories/index.md
+++ b/doc/ci/large_repositories/index.md
@@ -245,19 +245,11 @@ concurrent = 4
 This makes the cloning configuration to be part of the given runner
 and does not require us to update each `.gitlab-ci.yml`.
 
-## Git fetch caching or pre-clone step
-
-For very active repositories with a large number of references and files, you can either (or both):
-
-- Consider using the [Gitaly pack-objects cache](../../administration/gitaly/configure_gitaly.md#pack-objects-cache) instead of a
-  pre-clone step. This is easier to set up and it benefits all repositories on your GitLab server, unlike the pre-clone step that
-  must be configured per-repository. The pack-objects cache also automatically works for forks. On GitLab.com, where the pack-objects cache is
-  enabled on all Gitaly servers, we found that we no longer need a pre-clone step for `gitlab-org/gitlab` development.
-- Optimize your CI/CD jobs by seeding repository data in a pre-clone step with the
-  [`pre_clone_script`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section) of GitLab Runner. See
-  [SaaS runners on Linux](../runners/saas/linux_saas_runner.md#pre-clone-script-deprecated) for details.
-  Besides speeding up pipelines in large and active projects,
-  seeding the repository data also helps avoid
-  `429 Too many requests` errors from Cloudflare.
-  This error can occur if you have many runners behind a single,
-  IP address using NAT, that pulls from GitLab.com.
+## Git fetch caching step
+
+For very active repositories with a large number of references and files, consider using the
+[Gitaly pack-objects cache](../../administration/gitaly/configure_gitaly.md#pack-objects-cache).
+The pack-objects cache:
+
+- Benefits all repositories on your GitLab server.
+- Automatically works for forks.
diff --git a/doc/ci/runners/saas/linux_saas_runner.md b/doc/ci/runners/saas/linux_saas_runner.md
index e693c6ae5c1..f1ae1a368bc 100644
--- a/doc/ci/runners/saas/linux_saas_runner.md
+++ b/doc/ci/runners/saas/linux_saas_runner.md
@@ -101,123 +101,15 @@ SaaS runner instances are provisioned with a 25 GB storage volume. The underlyin
 is shared by the operating system, the Docker image, and a copy of your cloned repository.
 This means that the available free disk space that your jobs can use is **less than 25 GB**.
 
-## RAM disk (tmpfs)
+<!--- start_remove The following content will be removed on remove_date: '2023-08-22' -->
 
-If your workloads generate a lot of disk input/output, you can run them from a RAM disk instead.
+## Pre-clone script (removed)
 
-Add a `tmpfs` mount point as part of your CI job, and ensure that these operations run from that location:
-
-```yaml
-myjob:
-  before_script:
-    - mkdir -p mount/point
-    - mount -t tmpfs -o size=1G tmpfs mount/point
-```
-
-`tmpfs` stores any data written in RAM, and is paged out to swap if necessary, which generates input/output.
-To avoid this I/O, ensure that the combined memory needed by the workload plus the data written to `tmpfs` does not exceed
-the amount of RAM in the [runner machine type](#machine-types-available-for-private-projects-x86-64)
-selected for the job.
-
-The `free` command can be used to observe the state of memory use and potentially help explain why jobs
-intermittently run slowly or fail.
-
-```yaml
-  script:
-    - run_tests --workdir mount/point/
-    - free
-```
-
-If `buff/cache` is lower than normal or there is any swap used, this suggests that the server was under
-memory pressure. In the following example, `Swap: used` is not zero, and additionally
-compares `buff/cache` to a job which ran without any issues.
-
-```plaintext
-              total        used        free      shared  buff/cache   available
-Mem:        4396380      334028     3678404        3884      383948     3799128
-Swap:       1048572       69632      978940
-```
-
-## Pre-clone script (deprecated)
-
-WARNING:
 This feature was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/391896) in GitLab 15.9
-and is planned for removal in 16.0. Use [`pre_get_sources_script`](../../../ci/yaml/index.md#hookspre_get_sources_script) instead. This change is a breaking change.
-With SaaS runners on Linux, you can run commands in a CI/CD
-job before the runner attempts to run `git init` and `git fetch` to
-download a GitLab repository. The
-[`pre_clone_script`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section)
-can be used for:
-
-- Seeding the build directory with repository data
-- Sending a request to a server
-- Downloading assets from a CDN
-- Any other commands that must run before the `git init`
-
-To use this feature, define a [CI/CD variable](../../../ci/variables/index.md) called
-`CI_PRE_CLONE_SCRIPT` that contains a bash script.
-
-NOTE:
-The `CI_PRE_CLONE_SCRIPT` variable does not work on GitLab SaaS Windows or macOS runners.
-
-### Pre-clone script example
-
-This example was used in the `gitlab-org/gitlab` project until November 2021.
-The project no longer uses this optimization because the
-[pack-objects cache](../../../administration/gitaly/configure_gitaly.md#pack-objects-cache)
-lets Gitaly serve the full CI/CD fetch traffic. See [Git fetch caching](../../../development/pipelines/performance.md#git-fetch-caching).
-
-The `CI_PRE_CLONE_SCRIPT` was defined as a project CI/CD variable:
-
-```shell
-(
-  echo "Downloading archived master..."
-  wget -O /tmp/gitlab.tar.gz https://storage.googleapis.com/gitlab-ci-git-repo-cache/project-278964/gitlab-master-shallow.tar.gz
-
-  if [ ! -f /tmp/gitlab.tar.gz ]; then
-      echo "Repository cache not available, cloning a new directory..."
-      exit
-  fi
-
-  rm -rf $CI_PROJECT_DIR
-  echo "Extracting tarball into $CI_PROJECT_DIR..."
-  mkdir -p $CI_PROJECT_DIR
-  cd $CI_PROJECT_DIR
-  tar xzf /tmp/gitlab.tar.gz
-  rm -f /tmp/gitlab.tar.gz
-  chmod a+w $CI_PROJECT_DIR
-)
-```
-
-The first step of the script downloads `gitlab-master.tar.gz` from Google Cloud Storage.
-There was a [GitLab CI/CD job named `cache-repo`](https://gitlab.com/gitlab-org/gitlab/-/blob/5fb40526c8c8aaafc5f92eab36d5bbddaca3893d/.gitlab/ci/cache-repo.gitlab-ci.yml)
-that was responsible for keeping that archive up-to-date. Every two hours on a scheduled pipeline,
-it did the following:
-
-1. Create a fresh clone of the `gitlab-org/gitlab` repository on GitLab.com.
-1. Save the data as a `.tar.gz`.
-1. Upload it into the Google Cloud Storage bucket.
-
-When a job ran with this configuration, the output looked similar to:
-
-```shell
-$ eval "$CI_PRE_CLONE_SCRIPT"
-Downloading archived master...
-Extracting tarball into /builds/gitlab-org/gitlab...
-Fetching changes...
-Reinitialized existing Git repository in /builds/gitlab-org/gitlab/.git/
-```
-
-The `Reinitialized existing Git repository` message shows that
-the pre-clone step worked. The runner runs `git init`, which
-overwrites the Git configuration with the appropriate settings to fetch
-from the GitLab repository.
-
-`CI_REPO_CACHE_CREDENTIALS` must contain the Google Cloud service account
-JSON for uploading to the `gitlab-ci-git-repo-cache` bucket.
+and [removed](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29405) in 16.0.
+Use [`pre_get_sources_script`](../../../ci/yaml/index.md#hookspre_get_sources_script) instead.
 
-This bucket should be located in the same continent as the
-runner, or [you can incur network egress charges](https://cloud.google.com/storage/pricing).
+<!--- end_remove -->
 
 ## `config.toml`
 
diff --git a/doc/development/pipelines/performance.md b/doc/development/pipelines/performance.md
index d0eef0c86bd..b31d239eb6b 100644
--- a/doc/development/pipelines/performance.md
+++ b/doc/development/pipelines/performance.md
@@ -139,12 +139,3 @@ and `compile-production-assets` jobs to:
    This task is responsible for deciding if assets need to be compiled or not.
    It [compares the `HEAD` `SHA256` hexdigest from `$GITLAB_ASSETS_HASH` with the `master` hexdigest from `cached-assets-hash.txt`](https://gitlab.com/gitlab-org/gitlab/-/blob/c023191ef412e868ae957f3341208a41ca678403/lib/tasks/gitlab/assets.rake#L86).
 1. If the hashes are the same, we don't compile anything. If they're different, we compile the assets.
-
-## Pre-clone step
-
-NOTE:
-We no longer use this optimization for `gitlab-org/gitlab` because the [pack-objects cache](../../administration/gitaly/configure_gitaly.md#pack-objects-cache)
-allows Gitaly to serve the full CI/CD fetch traffic now. See [Git fetch caching](#git-fetch-caching).
-
-The pre-clone step works by using the `CI_PRE_CLONE_SCRIPT` variable
-[defined by GitLab.com shared runners](../../ci/runners/saas/linux_saas_runner.md#pre-clone-script-deprecated).
diff --git a/doc/update/removals.md b/doc/update/removals.md
index 9a2a3ac55fa..91af9d21a20 100644
--- a/doc/update/removals.md
+++ b/doc/update/removals.md
@@ -627,6 +627,18 @@ From GitLab 15.9, all Release links are external. The `external` field of the `R
 
 From GitLab 15.9, all Release links are external. The `external` field in the Releases and Release link APIs was deprecated in 15.9, and removed in GitLab 16.0.
 
+### Secure JWT token setting is removed
+
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">15.9</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading.
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/366798).
+</div>
+
+As part of [the deprecation of old versions of JSON web tokens](https://docs.gitlab.com/ee/update/deprecations.html#old-versions-of-json-web-tokens-are-deprecated), the **Limit JSON Web Token (JWT)** project setting has been removed. This setting was a temporary solution to help users transition to [ID tokens](https://docs.gitlab.com/ee/ci/secrets/id_token_authentication.html), as a way to switch between the old and new tokens, but the setting is no longer needed. In GitLab 16.0 and later, you can simply start using ID tokens in any job. When you use the `id_tokens` keyword in a job, that job uses only ID tokens and the old `CI_JOB_JWT*` tokens are not available. In jobs that do not use the `id_tokens` keyword, the old behavior remains unchanged.
+
+The old `CI_JOB_JWT*` tokens will be completely removed in GitLab 16.5, so you must switch to ID tokens before that release.
+
 ### Secure scanning `_DISABLED` variables now require the value `"true"`
 
 <div class="deprecation-notes">