git-resource icon indicating copy to clipboard operation
git-resource copied to clipboard

support shallow cloning on source

Open eedwards-sk opened this issue 5 years ago • 2 comments

This resource currently supports shallow cloning on a get step, however it does not appear to support shallow cloning for the source params.

This means that concourse seems to pull a full clone for the global 'cached' resource, and then pulls a shallow clone of THAT on a get step.

This is a problem for a workflow I have where I'm cloning the Homebrew Core Repo as it's an absolutely HUUUUUUUUGE repo with a bajillion commits, and it's designed to be cloned shallow from the start.

Currently this massive repo causes homebrew to take upwards of 1-2 minutes sometimes to start a build as it checks for new versions (even though the get step's depth is 1). I already have the automatic checking set to only once every 12 hours, but this doesn't fix it for triggering builds manually.

The only way to eliminate the performance issue is to get past the initial checkout and then pause the resource.

So, to summarize, this is a feature request to support a shallow clone for the 'source' (resource definition), not just on get steps.

eedwards-sk avatar Aug 21 '18 18:08 eedwards-sk

Quick note: per https://github.com/concourse/rfcs/pull/1 we're soon going to be moving towards starting resources off with the entire version history, rather than starting from "now".

So, like, that's the opposite of what you want here! However, I think we can/should still support some form of this: we can still do the big initial check to find everything to fit the v2 resource interface design, but maybe from then on we could do shallow clones. The resource can know to do this if there's a given version that we're checking from.

The net effect here would be that a newly configured pipeline would take a while to get everything, but every check thereafter (both periodic and from manually-triggered builds) would start off with a shallow clone instead, so it should still be much faster.

Would that be good enough?

vito avatar Aug 22 '18 15:08 vito

@vito Hey thanks for the response, yes, that would be a significant improvement!

eedwards-sk avatar Aug 22 '18 15:08 eedwards-sk