I’m trying to optimize our build. Up until recently, we had
dependenciestask that checked out from git, ran
yarn install, and
yarn compile, with caching around each of the four steps
dependenciesjob that just ran that task
- Three jobs that ran in parallel after the first job. Each ran the
dependenciestask before running tests. Because of the workflow graph, they would (almost) always get cache hits.
Based on this article, we recently changed that to use the workspace for persistence:
dependenciesjob that pulls from git, runs
yarn install, then
yarn compile, and pushes the whole working directory into the workspace. This job uses caches for all the dependencies.
- Three jobs that run in parallel after the first job. Each pulls the working directory from the workspace.
It turns out that’s slower. Unfortunately the
persist_to_workspace task doesn’t offer any transparency into what’s taking time but it definitely takes longer to persist to workspace than to write to cache.
Additionally, this post suggests that
persist_to_workspace can accept glob patterns, but I don’t see that information in the docs.
So my questions:
- Why is
- Should we use cache or workspaces for git? For ruby gems? For node modules? For compiled assets?
persist_to_workspaceaccept a glob? Does it accept a negative glob so I can ignore
./.git/but persist everything else?
- Can you update the docs with general guidelines about when to use each tool?