jenkinsci / jenkinsci/git-client-plugin

[JENKINS-75480] Git heavyweight checkout should use partial clone + sparse-checkout

Open
#1,694 1 comment 0 reactions 0 assignees View on GitHub
component:git-client-plugin imported-jira-issue priority:minor resolution:unresolved
Dominant language
Java
Stars
152
Forks
402
Avg merge
6h 47m
Merged PRs (30d)
4

Description

Hi,

We are using multibranch pipelines with "Merging the pull request with the current target branch revision" strategy. We are also using a SCM that do not provide capabilities for lightweight checkout.

As expected, Jenkins triggers a heavyweight checkout for each PR, which stores a full clone of the project for each PR branch.

We are already using some of the usual techniques to reduce bandwidth and storage, including:



  • setting sparse-checkout (but the sparse-checkout also applies to clones on agents)

  • manually setting reference repositories with a scheduled pull

  • scheduled git repack -adl to compress the clones

However, in the end, this doesn't scale.

Initial checkout for retrieving the Jenkinsfile could be vastly improved by updating the heavyweight checkout in the following way, provided that the version of git installed on the controller is recent enough:



  • perform a blobless --filter=blob:none --no-checkout clone

  • set up a sparse-checkout filter to only read the Jenkinsfile

  • perform a checkout and merge to read the Jenkinsfile

note: if the SCM doesn't support partial clone, git reverts the partial clone to a standard clone.

---
Originally reported by tdubouch, imported from: Git heavyweight checkout should use partial clone + sparse-checkout


  • status: Open
  • priority: Minor
  • component(s): git-client-plugin
  • resolution: Unresolved
  • votes: 1
  • watchers: 2
  • imported: 20251211-071809

Raw content of original issue

Hi,

We are using multibranch pipelines with "Merging the pull request with the current target branch revision" strategy. We are also using a SCM that do not provide capabilities for lightweight checkout.

As expected, Jenkins triggers a heavyweight checkout for each PR, which stores a full clone of the project for each PR branch.

We are already using some of the usual techniques to reduce bandwidth and storage, including:



  • setting sparse-checkout (but the sparse-checkout also applies to clones on agents)

  • manually setting reference repositories with a scheduled pull

  • scheduled git repack -adl to compress the clones

However, in the end, this doesn't scale.

Initial checkout for retrieving the Jenkinsfile could be vastly improved by updating the heavyweight checkout in the following way, provided that the version of git installed on the controller is recent enough:



  • perform a blobless --filter=blob:none --no-checkout clone

  • set up a sparse-checkout filter to only read the Jenkinsfile

  • perform a checkout and merge to read the Jenkinsfile

note: if the SCM doesn't support partial clone, git reverts the partial clone to a standard clone.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.