# Local build unusably slow

**URL:** <https://discuss.circleci.com/t/local-build-unusably-slow/22115>\
**Category:** Build Environment\
**Tags:** build-image\
**Created:** [May 2, 2018, 10:25am UTC](https://discuss.circleci.com/t/local-build-unusably-slow/22115 "2018-05-02T10:25:00Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![cherryfishmatt](https://avatars.discourse-cdn.com/v4/letter/c/85e7bf/32.png) [@cherryfishmatt](https://discuss.circleci.com/u/cherryfishmatt)\
**Post date:** [May 2, 2018, 10:25am UTC](https://discuss.circleci.com/t/local-build-unusably-slow/22115/1 "2018-05-02T10:25:00Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![halfer](https://sea2.discourse-cdn.com/circleci/user_avatar/discuss.circleci.com/halfer/32/9083_2.png) [@halfer](https://discuss.circleci.com/u/halfer)\
**Post date:** [May 2, 2018, 10:31am UTC](https://discuss.circleci.com/t/local-build-unusably-slow/22115/2 "2018-05-02T10:31:48Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![cherryfishmatt](https://avatars.discourse-cdn.com/v4/letter/c/85e7bf/32.png) [@cherryfishmatt](https://discuss.circleci.com/u/cherryfishmatt)\
**Post date:** [May 2, 2018, 12:44pm UTC](https://discuss.circleci.com/t/local-build-unusably-slow/22115/3 "2018-05-02T12:44:22Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![halfer](https://sea2.discourse-cdn.com/circleci/user_avatar/discuss.circleci.com/halfer/32/9083_2.png) [@halfer](https://discuss.circleci.com/u/halfer)\
**Post date:** [May 2, 2018, 12:48pm UTC](https://discuss.circleci.com/t/local-build-unusably-slow/22115/4 "2018-05-02T12:48:50Z")

</div>

> [@cherryfishmatt](#):
>
> A shallow clone may not include this revision

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?

> [@cherryfishmatt](#):
>
> 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?

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.

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/circleci/original/3X/5/1/511608acda8e85906e15909b57bd0a46c1dbe291.png) [@system](https://discuss.circleci.com/u/system)\
**Post date:** [July 31, 2018, 12:48pm UTC](https://discuss.circleci.com/t/local-build-unusably-slow/22115/5 "2018-07-31T12:48:57Z")

</div>

Closed on July 31, 2018, 12:48pm UTC

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.