We’re seeing cache issues across all our builds in today’s outage. All saving cache went through but restoring cache shows that “No cache is found for key…”. From the text of the banner, it’s unclear why cache is affected.
Here is what banner looks like today:
Partially Degraded Service - components affected: CircleCI UI, Google Cloud Platform Google Cloud Storage
Updated 25 min ago - Increased Bitbucket Permission Errors: We are continuing to work on a fix for this issue. We will provide an update in 20 minutes.
We have CI workflow depend on the restored cache so we wonder if cache is not something we can safely rely upon.
How are you using the cache? Is this a device to preserve files in jobs across a workflow? If so, I wonder if you should be using workspaces anyway, since that is designed for the purpose.
A missing cache should not fail your build. If it does, I would rework that to utilize Workspaces, artifacts, etc. The specific solution depends on what you’re doing.
That being said, cache shouldn’t be missing suddenly like this for all builds. Is this issue still happening? How are you generating the cache key?
Hi thanks for both of your prompt responses. Workspace definitely sounds like a better solution to our use case. On second thought, I’m not even sure the way we’re using any of these is necessary. let me share more details and your suggestions are very welcomed.
The use case is that we have a workflow that runs against a feature branch used for pull request. We define a “setup” job required by subsequent jobs like “test” and “lint”. In “setup”, we set the HEAD to a merged commit (merge from this branch and the master). The revision of the HEAD is cached and later restored in “test” and “lint”, followed by git reset to this exact revision. The idea is to ensure all jobs in a workflow work against the exact same code. Now I wonder if what we implement here is really needed. Perhaps CircleCI already has some mechanism to achieve this.
Would you post the sequence of git commands you are using? A basic checkout will do a clone in exactly the same way for all jobs in a workflow, so I am not sure what the reset additionally achieves.
And, while there is no harm in doing a checkout in all of your jobs, if you also have dependencies or other source build tasks, a workflow does sound like a good solution (it may be faster to restore a directory than do a fresh checkout+build for every job). Have a look at the Workflows section in the manual to see how this works.
