Merge remote-tracking branch 'dev/14-10-stable' into 14-10-stable

3 files changed, 32 insertions, 1 deletions

diff --git a/doc/ci/caching/index.md b/doc/ci/caching/index.md
index c634491662d..777bbf6053f 100644
--- a/doc/ci/caching/index.md
+++ b/doc/ci/caching/index.md
@@ -31,6 +31,7 @@ can't link to files outside it.
 - Subsequent pipelines can use the cache.
 - Subsequent jobs in the same pipeline can use the cache, if the dependencies are identical.
 - Different projects cannot share the cache.
+- Protected and non-protected branches do not share the cache.
 
 ### Artifacts
 
@@ -446,6 +447,22 @@ is stored on the machine where GitLab Runner is installed. The location also dep
 If you use cache and artifacts to store the same path in your jobs, the cache might
 be overwritten because caches are restored before artifacts.
 
+### Segregation of caches between protected and non-protected branches
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/330047) in GitLab 15.0.
+
+A suffix is added to the cache key, with the exception of the [fallback cache key](#use-a-fallback-cache-key).
+This is done in order to prevent cache poisoning that might occur through manipulation of the cache in a non-protected
+branch. Any subsequent protected-branch jobs would then potentially use a poisoned cache from the preceding job.
+
+As an example, assuming that `cache.key` is set to `$CI_COMMIT_REF_SLUG`, and that we have two branches `main`
+and `feature`, then the following table represents the resulting cache keys:
+
+| Branch name | Cache key |
+|-------------|-----------|
+| `main`      | `main-protected` |
+| `feature`   | `feature-non_protected` |
+
 ### How archiving and extracting works
 
 This example shows two jobs in two consecutive stages:
diff --git a/doc/ci/jobs/index.md b/doc/ci/jobs/index.md
index b8129e1cf18..e589fd8b045 100644
--- a/doc/ci/jobs/index.md
+++ b/doc/ci/jobs/index.md
@@ -167,7 +167,7 @@ The jobs are ordered by comparing the numbers from left to right. You
 usually want the first number to be the index and the second number to be the total.
 
 [This regular expression](https://gitlab.com/gitlab-org/gitlab/-/blob/2f3dc314f42dbd79813e6251792853bc231e69dd/app/models/commit_status.rb#L99)
-evaluates the job names: `([\b\s:]+((\[.*\])|(\d+[\s:\/\\]+\d+)))+\s*\z`.
+evaluates the job names: `([\b\s:]+((\[.*\])|(\d+[\s:\/\\]+\d+))){1,3}\s*\z`.
 One or more `: [...]`, `X Y`, `X/Y`, or `X\Y` sequences are removed from the **end**
 of job names only. Matching substrings found at the beginning or in the middle of
 job names are not removed.
diff --git a/doc/ci/pipelines/schedules.md b/doc/ci/pipelines/schedules.md
index 8813f3e1d59..8ab80e3798a 100644
--- a/doc/ci/pipelines/schedules.md
+++ b/doc/ci/pipelines/schedules.md
@@ -39,6 +39,20 @@ To add a pipeline schedule:
      These variables are available only when the scheduled pipeline runs,
      and not in any other pipeline run.
 
+## Edit a pipeline schedule
+
+> Introduced in GitLab 14.8, only a pipeline schedule owner can edit the schedule.
+
+The owner of a pipeline schedule can edit it:
+
+1. On the top bar, select **Menu > Projects** and find your project.
+1. In the left sidebar, select **CI/CD > Schedules**.
+1. Next to the schedule, select **Edit** (**{pencil}**) and fill in the form.
+
+The user must have the Developer role or above for the project. If the user is
+not the owner of the schedule, they must first [take ownership](#take-ownership)
+of the schedule.
+
 ## Run manually
 
 To trigger a pipeline schedule manually, so that it runs immediately instead of