Skip to content
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

Use GitVersion to parse version from discovery #2312

Conversation

kevinrizza
Copy link
Member

Fix an issue with the new catalog templating controller where it was incorrectly parsing the version field from discovery. Instead, directly use the gitVersion value to match the behavior for minKubeVersion requirement parsing.

@openshift-ci openshift-ci bot requested review from anik120 and timflannagan August 3, 2021 13:17
@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 3, 2021
serverGitVersion, err := semver.Parse(serverVersion.GitVersion)
// need to use the gitversion from version.info.String() because minor version is not always Uint value
// and patch version is not returned as a first class field
semver, err := semver.Parse(strings.Split(strings.TrimPrefix(serverVersion.String(), "v"), "-")[0])
Copy link
Member

Choose a reason for hiding this comment

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

Just a quick thought - the apimachinery util package has parsing functions available that output a struct, and methods on that struct for retrieving major/minor/patch fields as uints, so you wouldn't need to also convert the string representation to a uint later.

@kevinrizza kevinrizza force-pushed the fix-server-version-parsing-catalog-template branch from 6fddfd1 to 1da2cb0 Compare August 3, 2021 19:43
Copy link
Member

@ecordell ecordell left a comment

Choose a reason for hiding this comment

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

/approve

we should consider using this for the minkubeversion as well, though I'm less concerned about updating that if it's going to be replaced with runtime constraints soon

"github.com/sirupsen/logrus"
versionUtil "k8s.io/apimachinery/pkg/util/version"
Copy link
Member

Choose a reason for hiding this comment

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

supernit: usually lowercase module names?

@openshift-ci
Copy link

openshift-ci bot commented Aug 3, 2021

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ecordell, kevinrizza

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

The pull request process is described here

Needs approval from an approver in each of these files:
  • OWNERS [ecordell,kevinrizza]

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

@timflannagan
Copy link
Member

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Aug 3, 2021
In some cases, the discovery client can return a kube server version
with the minor version field as a non uint value. To properly parse the
value and get all version fields correctly, instead directly parse the
GitVersion string for all values of the kube server version
@kevinrizza kevinrizza force-pushed the fix-server-version-parsing-catalog-template branch from 1da2cb0 to f391ebb Compare August 3, 2021 20:14
@openshift-ci openshift-ci bot removed the lgtm Indicates that a PR is ready to be merged. label Aug 3, 2021
@timflannagan
Copy link
Member

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Aug 3, 2021
@openshift-ci openshift-ci bot merged commit 31350db into operator-framework:master Aug 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants