Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Hi @sarkar-deb. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is NOT APPROVED

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

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

This can cause downstream tooling and image tagging logic to behave incorrectly or inconsistently.

downstream tooling is responsible to do one of these things:

1. do a clone with enough git tag info that these build scripts work as-is
2. set KUBE_GIT_VERSION using its own logic and use these build scripts
3. set the version ldflags using its own logic in its own build scripts

if our scripts are allowing a build to proceed with KUBE_GIT_VERSION completely unset or invalid, erroring more visibly seems reasonable, but I don't think we need to add new ways of deriving version info in this script... the git tag or manual override of KUBE_GIT_VERSION seems reasonable to me

@liggitt
Thanks I got your point as of different ways to get git version while building binary.
But my point was like instead of passing idflags while building kubelet why cannot we use a version data, by this we can ensure that we are using correct code base as intended else we could have a case where in we are using release of 1.32 and while building we have unknowing added version as 1.31(as shown in code block below). So, to avoid that confusion I was suggesting this PR.

KUBE_GIT_VERSION="1.31.0"
KUBE_GIT_COMMIT=$(git rev-parse HEAD)
KUBE_GIT_TREE_STATE=clean
KUBE_GIT_MAJOR=$(echo $KUBE_GIT_VERSION | sed 's/v\([0-9]*\)\..*/\1/')
KUBE_GIT_MINOR=$(echo $KUBE_GIT_VERSION | sed 's/v[0-9]*\.\([0-9]*\).*/\1/')
LDFLAGS="-X [k8s.io/component-base/version.gitVersion=$](http://k8s.io/component-base/version.gitVersion=$){KUBE_GIT_VERSION} \
         -X [k8s.io/component-base/version.gitCommit=$](http://k8s.io/component-base/version.gitCommit=$){KUBE_GIT_COMMIT} \
         -X [k8s.io/component-base/version.gitTreeState=$](http://k8s.io/component-base/version.gitTreeState=$){KUBE_GIT_TREE_STATE} \
         -X [k8s.io/component-base/version.gitMajor=$](http://k8s.io/component-base/version.gitMajor=$){KUBE_GIT_MAJOR} \
         -X [k8s.io/component-base/version.gitMinor=$](http://k8s.io/component-base/version.gitMinor=$){KUBE_GIT_MINOR}"
go build -ldflags "$LDFLAGS" ./cmd/kubelet

@BenTheElder
I am open to pick version from any other path if you guide me, as per my understanding I have used that path and have checked that we update version every release and currently master branch has version as v1.33.0-go1.24.2-bullseye.0

There are two approaches today:

1. clone the repo normally and use the build scripts that derive versions from git tags
2. clone the repo differently and override the version by setting KUBE_GIT_VERSION, etc

I don't think we should add a third way to derive version tags. If we want to try to improve detection of when the repo was not cloned normally build scripts are deriving unexpected git tags and error sooner, that could be ok if it is straightforward and reliable.

If we want to try to improve detection of when the repo was not cloned normally build scripts are deriving unexpected git tags and error sooner, that could be ok if it is straightforward and reliable.

@liggitt , when git has given a way to perform shallow clone, why would we go and fail build rather we can use a way to derive versions and get it moving. Hope I got your comment correctly.

@liggitt , when git has given a way to perform shallow clone, why would we go and fail build rather we can use a way to derive versions and get it moving.

Doing a shallow clone is perfectly fine, but you are then responsible to provide the missing tag information by setting KUBE_GIT_VERSION. We don't want to add a second way to derive the version, especially since it will not be used by the official Kubernetes release, and will therefore be very likely to atrophy / stop working randomly.

@liggitt , when git has given a way to perform shallow clone, why would we go and fail build rather we can use a way to derive versions and get it moving. Hope I got your comment correctly.

you're not deriving the version in this PR, please see the comments on the issue linked above #131629 (comment)

Also, there are better alternatives to shallow clone (see the comment linked ... #131629 (comment))

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale