Wipe 

In general the Intelligent Cache will function without the need for any intervention, but it may occasionally be useful to wipe the cache. Some scenarios when a wipe may be useful are as follows.

• CI structure changes
• Tooling changes
• Data corruption

Impact 

Wiping the cache will not impact running jobs, nor subsequent jobs in an active pipeline. Pipelines started after a wipe will only utilize cache data created after the wipe.

The performance benefits provided by the cached data will be unavailable until the cache is repopulated. Therefore, wiping the cache should be avoided whenever possible.

Usage 

To wipe all caches use cache wipe as shown below.

ssh git@api.cedarci.com cache wipe

To see all options:

ssh git@api.cedarci.com cache --help

Index 

The following is an example config containing two enhanced runners.

[[gitlab.enhanced.runner]] # index: 0
token = "abc"
api_token = "def"

[[gitlab.enhanced.runner]] # index: 1
token = "ghi"
api_token = "jkl"

To only wipe the second runner's cache the index 1 would be used.

ssh git@api.cedarci.com cache wipe 1

Collection 

The CEDARCI_COLLECTION variable can be used to effectively wipe the cache alongside breaking changes. Depending on the workflow and team size this can be rather useful to allow for self-management.

Consider the following example in which best/toolchain is upgraded from version 1.2.3 to 2.1.2, but since the upgrade introduces a backward incompatible change the CEDARCI_COLLECTION is changed to effectively start from a fresh cache.

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index df9c3d4..2eeff27 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -1,7 +1,7 @@
 variables:
-  CEDARCI_COLLECTION: "01"
+  CEDARCI_COLLECTION: "02"
 
 build:
   stage: build
-  image: best/toolchain:1.2.3
+  image: best/toolchain:2.1.2
   script: compile