Submit Your Ideas

We want to hear from you - vote for the features and improvements you'd most like to see, or submit your own ideas if you don't find them already listed.

Allow for Shallow Clone command in 2.0

As per


It would be nice for users to have a way to shallow clone. Currently, we do `checkout` to checkout. It would be nice to be able to pass a depth into that like `shallowClone:10` and then use the number `10` as the depth for the clone. The PR linked has a modified version of the existing script that works.

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Feb 27 2018
  • Future consideration
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    27 Feb 19:54

    Would be nice to have this since it is a default behavior of Travis-CI.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    31 Mar 13:38

    CircleCI, I think this is more than a nice to have. Previously with circle 1.0 we had sub 30s checkouts. Now with 2.0 we have 15m checkouts. That's a crazy increase in build time. I read in a comment on github that the decision is based on the fact that github doesn't want you doing shallow clones because of CPU usage.

    Essentially what you're saying to your customers is "if you want fast checkouts, use travis or some other provider"

    This change + the crazy "requirement" to use match for code signing, really feel like a step backwards with 2.0 instead of what we all hoped to be an improvement on an already great platform.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    14 Jun 23:50

    I had good results manually caching the git repo, using steps like these:

    - &cache_restore_git
    name: Restoring cache - git
    - cache-git-{{ .Branch }}-{{ .Revision }}
    - cache-git-{{ .Branch }}
    - cache-git-staging-
    - cache-git-

    - &cache_save_git
    name: Saving cache - git
    key: cache4-git-{{ .Branch }}-{{ .Revision }}
    - ~/myproject/

    and then use


    after the checkout step in one of the first jobs and


    before the checkout step in all others.


    I could see that getting slower for very big repos, but I guess that's kinda unavoidable without knowing what machines your build runs on.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    24 Sep 16:38

    I'd love to have this ability. We attempted to use the cacheing step for our source as Jonas T suggests, but the cache fails about 30% of time time, which means the whole build fails. Not ideal. Any idea as to if/when this will be implemented?

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    22 Nov 02:20

    Does this help?