search

concourse / pool-resource

atomically manages the state of the world (e.g. external environments)
Apache License 2.0
54 stars 36 forks source link

Adds optional depth parameter for specifying the number of git commits #50

Closed maryamklabib closed 4 years ago

maryamklabib commented 5 years ago

"Some of the lock repos can get super big really fast, especially if multiple teams/pipelines are using the same repo. An idea is to use shallow clones, since we don't necessarily need the full history of the repo, we just need the latest state."

We wanted to implement the behavior that was requested in issue: https://github.com/concourse/pool-resource/issues/40

This behaves the same exact way as the git-resource, as we wanted to maintain consistency. This is a parameter on the get step, the same way as described here: https://github.com/concourse/git-resource#in-clone-the-repository-at-the-given-ref

Authored-by: Maryam Labib mlabib@pivotal.io co-authored by: Soumya GB gowdabas@usc.edu

Signed off by: Maryam Labib mlabib@pivotal.io Signed off by: Soumya GB gowdabas@usc.edu

maryamklabib commented 5 years ago

Any updates on merging this PR?

sc68cal commented 4 years ago

Is there ever a time where we wouldn't want the depth to be 1?

I'd suggest setting the default value to be 1 so that users that end up with big lock pool histories don't have to go and hunt for this parameter once their lock pool gets big enough for this to be a problem. I haven't looked through the code for this resource, but if there isn't any conflict resolution in this repo for handling history merges, what is the point of downloading all the history?