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 https://github.com/circleci/circleci-docs/issues/2040#issuecomment-368139737

 

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
    February 27, 2018 19:54

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    June 14, 2018 23:50

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

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

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

    and then use

    *cache_save_git

    after the checkout step in one of the first jobs and

    *cache_restore_git

    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
    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?