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.

  • Guest
  • Feb 27 2018
  • Taking votes
  • Attach files
  • Ricardo Oliveira commented
    19 Jun 11:46

    A shallow clone should even be the default I'd think.

  • Steve Sims commented
    19 Jun 11:21

    FYI, shallow cloning is the default in GitHub CI's checkout action, defaulting to a depth of 1

  • Hirokuni Kim commented
    November 22, 2018 02:20

    Does this help?

  • Brett Hardin commented
    September 24, 2018 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?

  • Jonas T commented
    June 14, 2018 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.

  • Wes Billman commented
    March 31, 2018 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.

  • Michael Carrano commented
    February 27, 2018 19:54

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