Within one job, save_cache and restore_cache works well, but why not allow that to cross jobs within one workflow? It’s not clear to me the purpose difference between a persisted workspace and saved cache.
Does it work for you to choose a cache key that’s unique to the current workflow? E.g. some key based on
One caveat of this is that the
$CIRCLE_WORKFLOW_* environment variables don’t seem to exist e.g. when you retry an individual job from a workflow. If you want to keep the cache across individual job retries, I think the closest to being unique and persistent across retries is the
$CIRCLE_SHA1. I’m e.g. using that to pass down previous test timings from the first build of a workflow, since the other builds don’t get them passed in by default.
Edit: Actually, it seems like
$CIRCLE_WORKFLOW_WORKSPACE_ID is the only workflow environment variable that stays the same across retries as long as you use the “Rerun failed jobs” from the “Rerun” dropdown menu on the workflow detail page:
It seems like I was mistaken about being able to use caching across jobs in the same workflow. I have no problems restoring cache across several jobs in a workflow, provided they have the ability to generate the same key.
I think that deepens my question though, what is the difference between a persisted workspace and caching? Why would I chose one over the other?
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.