Git clone depth is a surprisingly powerful lever to pull for controlling Drone CI build times and disk space usage.
Let’s watch it in action. Imagine this simple .drone.yml:
kind: pipeline
type: docker
name: default
steps:
- name: checkout
image: plugins/git
settings:
depth: 5 # This is the magic number
When Drone runs this pipeline, the plugins/git step executes a git clone --depth 5 <repo_url> command in the workspace. Instead of downloading the entire Git history, it only fetches the last 5 commits. This means the workspace on the build agent is significantly smaller, and the clone operation itself is much faster.
The core problem Git clone depth solves is the overhead associated with cloning large repositories. Many CI/CD workflows only need the latest code to build and test. Fetching the entire history, which can span years and thousands of commits, is often unnecessary and computationally wasteful. This impacts:
- Build Time: A faster clone directly translates to a faster overall pipeline execution.
- Disk Space: Smaller workspaces mean less disk I/O and less storage consumed on build agents.
- Network Usage: Less data transferred from the Git remote.
Internally, the plugins/git (and similarly, the core Git client when you run git clone) uses the --depth flag. This flag tells Git to perform a "shallow clone." A shallow clone creates a history with a specified number of commits. For example, git clone --depth 1 fetches only the very latest commit. git clone --depth 10 fetches the latest 10 commits. The plugins/git simply exposes this functionality through its depth setting.
The primary lever you control is the depth value in your .drone.yml. Choosing the right depth is a trade-off:
depth: 1: Fastest clone, smallest workspace. Ideal if your build only depends on the absolute latest code and doesn’t need to inspect older commits for any reason (e.g., generating changelogs that span multiple versions).depth: 10ordepth: 20: A good balance. Still significantly faster than a full clone, but provides enough history for most common CI tasks like running tests that might rely on diffs or generating basic version information.- Full Clone (no
depthspecified): The default behavior. Fetches all history. Necessary only if your build process explicitly needs to access older commits, such as complex release management scripts or historical code analysis.
The most surprising mechanical consequence of a shallow clone is how Git handles operations that require more history than is present. If your build script, for instance, tries to do git log --since=2.weeks.ago on a --depth 1 clone, it will fail. Git will report that it doesn’t have enough history. You’ll need to fetch more history. The plugins/git can do this with the fetch setting, which can be set to true and then you can specify depth again to fetch more commits. For example, depth: 1 and fetch: true with depth: 10 would first clone the latest commit, then fetch 9 more to get a total depth of 10.
The next concept you’ll likely encounter is managing multiple Git repositories within a single Drone pipeline and how clone depth applies to each.