So I’ve seen a few related issues, but they’re all closed so I couldn’t ask for information there.
I’m running circleci against a monorepo, and debugging the build on my local machine (OSX 10.13.4, circleci --version 0.0.5132-8289ad4)
And the “Checkout code” step is painfully slow (up to 10 minutes). When I run git clean -xdf first, the build is < 1 minute. I would guess that the checkout code step locally does not respect the .gitignore files, and there is some inefficiency in passing the many, many files in the node_modules folders in my project.
Is this a bug or a feature of the local circleci build tool?
If it’s a monorepo, could you drop the checkout step and do a Git shallow clone, assuming that’s all you need? You might be pulling much less data. I think you’d need to set up your SSH keys manually, but that’s doable.
Decided against acting on this, at least for now, as I’m not sure what the logic should be for deciding how deep to clone, e.g. am I running an old build again? A shallow clone may not include this revision
As this isn’t (currently) holding back our team, I’ll just accept the slow build, but I welcome any more ideas on how I or other teams might tackle this issue.
Incidentally, in terms of setting up keys, I was planning on baking them into the docker image we are using to build. Does this seem like a sane approach?
I believe the required hash is provided as an env var, so you’d just do a shallow clone to that hash. Try a full clone and a shallow clone locally to see how much data is transferred in each case?
For low-value keys, I do this. Otherwise put them in env vars or context env vars in CircleCI itself, where they are (in theory) harder to steal.