Missing vX.Y.Z tags cause wrong version report

[krouma]

Hi, I successfully built the oc tool from source, but when I run oc version it reports Client Version: v4.2.0-alpha.0-1997-g0c63f9d. However, I am at the tag openshift-clients-4.14.0-202310201027.

I looked for the cause and found that during make oc, the command git describe --long --tags --abbrev=7 --match 'v[0-9]*' || echo 'v0.0.0-unknown-$(SOURCE_GIT_COMMIT)' is run. It looks for the latest tag in v<version> format. However, the last tag, that satisfies this format, is v4.2.0-alpha.0.

I know I can get around this by setting SOURCE_GIT_TAG or OS_GIT_VERSION to v4.14.0, but for me the correct solution seems to be adding appropriate tags to make the auto-detection work.

[codespearhead]

I noticed that problem in a series of issues in the OKD repository, but I'm not familiar with tags, so I'm unable to properly troubleshoot what commit introduced this bug.

Are you @krouma ?

[krouma]

This is not a problem of the code, so there's no commit to pinpoint. The tags probably exist only in private repos and are not synchronized here.

[codespearhead]

Do you mean these tags?

[krouma]

Yes, but those that are present have wrong format.

[codespearhead]

Then will this solve the issue?

-SOURCE_GIT_TAG ?=$(shell git describe --long --tags --abbrev=7 --match 'v[0-9]*' || echo 'v0.0.0-unknown-$(SOURCE_GIT_COMMIT)')
+SOURCE_GIT_TAG ?=$(shell git describe --long --tags --abbrev=7 --match 'openshift-clients-*' | sed 's/openshift-clients-/v/g' || echo 'v0.0.0-unknown-$(SOURCE_GIT_COMMIT)')

# Input: openshift-clients-4.15.0-202402082307
# Output: v4.15.0-202402082307

[krouma]

I guess it would

[codespearhead]

I've just created a PR.

Do you have the bandwidth to check if that branch fixes this problem? I'm confused as to how to build it from source to do so myself.

If so, a PR review will be appreciated.

[Bengrunt]

Thank you so much for taking a look at this @codespearhead 👍

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[codespearhead]

/lifecycle frozen