As Google Cloud Storage interprets consecutive slashes differently from Unix/Linux Path Resolution Algorithm, restore_cache cannot find the cache object created by save_cache in case of presence of a trailing slash in the --bucket argument supplied identically to both of the commands, as in the following example:
cloudbuild.yaml
steps:
- name: 'gcr.io/$PROJECT_ID/restore_cache'
id: restore_gradle_cache
args:
- '--bucket=gs://${_GRADLE_CACHE_BUCKET}/' # here the slash makes cache file existence check to fail
- '--key=${_GRADLE_CACHE_KEY}'
...
- name: 'gcr.io/$PROJECT_ID/save_cache'
id: save_gradle_cache
args:
- '--bucket=gs://${_GRADLE_CACHE_BUCKET}/'
- '--key=${_GRADLE_CACHE_KEY}'
- '--path=${_GRADLE_USER_HOME}/caches'
- '--path=${_GRADLE_USER_HOME}/wrapper'
options:
dynamic_substitutions: true
substitutions:
_GRADLE_CACHE_BUCKET: ${PROJECT_ID}_cloudbuild/gradle_cache
...
As Google Cloud Storage interprets consecutive slashes differently from Unix/Linux Path Resolution Algorithm,
restore_cache
cannot find the cache object created bysave_cache
in case of presence of a trailing slash in the--bucket
argument supplied identically to both of the commands, as in the following example:cloudbuild.yaml