Skip to content

Initializing shallow cloning logic and CRD change #1824

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

ayushsatyam146
Copy link
Member

@ayushsatyam146 ayushsatyam146 commented Mar 4, 2025

Changes

Submitter Checklist

  • Includes tests if functionality changed/was added
  • Includes docs if changes are user-facing
  • Set a kind label on this PR
  • Release notes block has been filled in, or marked NONE

See the contributor guide
for details on coding conventions, github and prow interactions, and the code review process.

Release Notes

The source.git.depth is added in the Builds CRD and the Builds API. This field now specifies the depth of the Git history cloning. If not specified the value defaults to 1 and a shallow clone is performed. Values greater than 1 will create a clone with the specified depth.

@pull-request-size pull-request-size bot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label Mar 4, 2025
@ayushsatyam146 ayushsatyam146 marked this pull request as draft March 4, 2025 12:36
Copy link
Member

@adambkaplan adambkaplan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great ideas here - 👍 to adding this to the API. I have a suggestion on the field naming, plus I noticed the current draft includes a breaking behavior change.

The only items missing IMO are tests. I think this would need the following:

  1. Unit test(s) to verify we are passing the right arguments to the git clone command.
  2. End to end test(s) that inspect git history from one of our sample repositories during the build (ex: as a RUN command in a Dockerfile)

Comment on lines 63 to 71
// ShallowCloneDepth specifies the depth of the shallow clone.
// If not specified or set to 0, a full clone will be performed.
// Values greater than 0 will create a shallow clone with the specified depth.
//
// +optional
ShallowCloneDepth *int `json:"shallowCloneDepth,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would simplify the name of this field to "Depth". This matches the --depth flag in the git command line.

Suggested change
// ShallowCloneDepth specifies the depth of the shallow clone.
// If not specified or set to 0, a full clone will be performed.
// Values greater than 0 will create a shallow clone with the specified depth.
//
// +optional
ShallowCloneDepth *int `json:"shallowCloneDepth,omitempty"`
// Depth specifies the git clone depth. If set to 0, cloning will include the full source history.
// Values greater than 0 will create a shallow clone with the specified history depth.
//
// +optional
Depth *int `json:"depth,omitempty"`

// If not specified or set to 0, a full clone will be performed.
// Values greater than 0 will create a shallow clone with the specified depth.
//
// +optional
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would default this value to 1 so that we do not introduce a breaking change, and add a validation that this must be greater than or equal to 0.

Suggested change
// +optional
// +optional
// +default=1
// +kubebuilder:validation:Minimum=0

Comment on lines 82 to 89
// Check if shallow clone is requested
if source.ShallowCloneDepth != nil && *source.ShallowCloneDepth > 0 {
gitStep.Args = append(
gitStep.Args,
"--depth",
fmt.Sprintf("%d", *source.ShallowCloneDepth),
)
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 if we set a default value of 1, and validate that Depth must be >= 0, can we simply pass the depth value as-is?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we still need the nil-check. I am not 100 % sure whether k8s api server with default=1 will actually set it on create/update operations. But even if so, for existing objects it will be nil.

cmd/git/main.go Outdated
Comment on lines 96 to 100
pflag.UintVar(&flagValues.depth, "depth", 1, "Create a shallow clone based on the given depth")
// Setting depth to 0 means no shallow clone (full clone)
pflag.UintVar(&flagValues.depth, "depth", 0, "Create a shallow clone with the given depth. 0 means full clone (no shallow).")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a breaking change - current Shipwright users will see a performance hit if we switch from "no history" when cloning to "full history." I recommend reverting this change.

cmd/git/main.go Outdated
Comment on lines 123 to 128
flagValues = settings{depth: 1}
flagValues = settings{depth: 0}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Likewise - please revert so we don't change the current behavior of cloning source.

cmd/git/main.go Outdated
@@ -266,6 +267,7 @@ func clone(ctx context.Context) error {
cloneArgs = append(cloneArgs, "--branch", flagValues.revision)
}

// Only add depth if it's greater than 0 (meaning shallow clone is requested)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 great comment.

@SaschaSchwarze0 SaschaSchwarze0 added the kind/feature Categorizes issue or PR as related to a new feature. label Mar 6, 2025
@SaschaSchwarze0 SaschaSchwarze0 added the kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API label Mar 16, 2025
Copy link
Contributor

openshift-ci bot commented May 8, 2025

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign adambkaplan for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@pull-request-size pull-request-size bot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels May 12, 2025
@ayushsatyam146 ayushsatyam146 marked this pull request as ready for review May 12, 2025 11:32
@openshift-ci openshift-ci bot requested review from adambkaplan and qu1queee May 12, 2025 11:32
@openshift-ci openshift-ci bot added the release-note Label for when a PR has specified a release note label May 12, 2025
@ayushsatyam146
Copy link
Member Author

@adambkaplan @SaschaSchwarze0 I have made all the required changes and also added tests and docs changes. Can you please review again. Thanks

@ayushsatyam146 ayushsatyam146 force-pushed the shallow-clone branch 2 times, most recently from d3959cc to af9d83e Compare May 15, 2025 08:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API kind/feature Categorizes issue or PR as related to a new feature. release-note Label for when a PR has specified a release note size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

3 participants