89
Allow for Shallow Clone command in 2.0
D
David Aghassi
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.CCI-I-254
Manuel Fittko
weird, that this is still not offered, could be a simple optional param or env var for the
checkout
step, no?S
Surenkumar Nihalani
Can we prioritize this please?
R
Ricardo Oliveira
A shallow clone should even be the default I'd think. https://github.com/circleci/circleci-docs/issues/2040#issuecomment-646590921
S
Steve Sims
FYI, shallow cloning is the default in GitHub CI's checkout action, defaulting to a depth of 1
H
Hirokuni Kim
Does this help? https://circleci.com/orbs/registry/orb/ganta/git
B
Brett Hardin
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?
J
Jonas T
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.
W
Wes Billman
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.
M
Michael Carrano
Would be nice to have this since it is a default behavior of Travis-CI.