ART-11111: versioning scheme decides the right param value for Jira t… #1083
Conversation
…emplate rh-pre-commit.version: 2.3.1 rh-pre-commit.check-secrets: ENABLED
openshift-ci-robot
added
the
jira/valid-reference
|
@mbiarnes: This pull request references ART-11111 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.18.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: 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 |
|
@mbiarnes: The following test failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
| @@ -134,6 +134,9 @@ async def run(self): | |||
| release_config = releases_config.get("releases", {}).get(self.assembly, {}) | |||
| self.release_name = get_release_name_for_assembly(self.group_name, releases_config, self.assembly) | |||
| self.release_version = semver.VersionInfo.parse(self.release_name).to_tuple() | |||
| # Convert string to an integer if necessary (like 4.20.0-0 will result in | |||
There was a problem hiding this comment.
Not sure why the line above does to_tuple(). the semver.version.Version instance has nice attributes:
>>> v = semver.VersionInfo.parse('4.5.6-1')
>>> v.to_dict()
{'major': 4, 'minor': 5, 'patch': 6, 'prerelease': '1', 'build': None}
>>> v.major
4
But this makes me realize that the proposed versioning scheme is not semver compliant.
Most standard compliant solution would be to have this in the build info.
>>> semver.VersionInfo.parse('4.5.6-1')
Version(major=4, minor=5, patch=6, prerelease='1', build=None)
>>> semver.VersionInfo.parse('4.5.6-rc.0-0')
Version(major=4, minor=5, patch=6, prerelease='rc.0-0', build=None)
meaning, for an RC, semver does not understand semantically understand what is going on.
The scheme to denote our build after a + seems the standard way of doing it:
>>> semver.VersionInfo.parse('4.5.6-rc.0+0')
Version(major=4, minor=5, patch=6, prerelease='rc.0', build='0')
>>> semver.VersionInfo.parse('4.5.6-rc.0+1')
Version(major=4, minor=5, patch=6, prerelease='rc.0', build='1')
>>> semver.VersionInfo.parse('4.5.7+1')
Version(major=4, minor=5, patch=7, prerelease=None, build='1')
There was a problem hiding this comment.
The doubt about the versioning scheme is resolved, + is not a valid token for a k8s object. We need to deviate from semver.
| "x": self.release_version[0], | ||
| "y": self.release_version[1], | ||
| "z": self.release_version[2], | ||
| "x": x, |
There was a problem hiding this comment.
would rather use the attributes semver returns,
self.release_version = semver.VersionInfo.parse(self.release_name)
# so here it becomes
"x": self.release_version.major
…emplate
rh-pre-commit.version: 2.3.1
rh-pre-commit.check-secrets: ENABLED