From a1816ff0e60ad7546c9f4e28e86e502c951bb0ca Mon Sep 17 00:00:00 2001
From: Evan Read <eread@gitlab.com>
Date: Fri, 7 Jun 2019 08:00:41 +0000
Subject: SSoT audit fixes

Implements part of the single source of truth audit
fixes for the CI section.
---
 doc/ci/caching/index.md | 24 +++++++++++++++++++-----
 1 file changed, 19 insertions(+), 5 deletions(-)

(limited to 'doc/ci/caching/index.md')

diff --git a/doc/ci/caching/index.md b/doc/ci/caching/index.md
index d703e106e76..9a5a3624c73 100644
--- a/doc/ci/caching/index.md
+++ b/doc/ci/caching/index.md
@@ -1,3 +1,7 @@
+---
+type: index, concepts, howto
+---
+
 # Cache dependencies in GitLab CI/CD
 
 GitLab CI/CD provides a caching mechanism that can be used to save time
@@ -60,7 +64,7 @@ In summary:
 
 - Caches are disabled if not defined globally or per job (using `cache:`).
 - Caches are available for all jobs in your `.gitlab-ci.yml` if enabled globally.
-- Caches can be used by subsequent pipelines of that very same job (a script in
+- Caches can be used by subsequent pipelines of that same job (a script in
   a stage) in which the cache was created (if not defined globally).
 - Caches are stored where the Runner is installed **and** uploaded to S3 if
   [distributed cache is enabled](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching).
@@ -87,7 +91,7 @@ cache, when declaring `cache` in your jobs, use one or a mix of the following:
   that share their cache.
 - [Use sticky Runners](../runners/README.md#locking-a-specific-runner-from-being-enabled-for-other-projects)
   that will be only available to a particular project.
-- [Use a `key`](../yaml/README.md#cachekey) that fits your workflow (e.g.,
+- [Use a `key`](../yaml/README.md#cachekey) that fits your workflow (for example,
   different caches on each branch). For that, you can take advantage of the
   [CI/CD predefined variables](../variables/README.md#predefined-environment-variables).
 
@@ -420,7 +424,7 @@ mismatch and a few ideas how to fix it.
 
 Let's explore some examples.
 
----
+#### Examples
 
 Let's assume you have only one Runner assigned to your project, so the cache
 will be stored in the Runner's machine by default. If two jobs, A and B,
@@ -462,8 +466,6 @@ job B:
 
 To fix that, use different `keys` for each job.
 
----
-
 In another case, let's assume you have more than one Runners assigned to your
 project, but the distributed cache is not enabled. We want the second time the
 pipeline is run, `job A` and `job B` to re-use their cache (which in this case
@@ -526,3 +528,15 @@ Behind the scenes, this works by increasing a counter in the database, and the
 value of that counter is used to create the key for the cache by appending an
 integer to it: `-1`, `-2`, etc. After a push, a new key is generated and the
 old cache is not valid anymore.
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, e.g. `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->
-- 
cgit v1.2.3