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

Test Information #1529

Merged
merged 1 commit into from
Oct 22, 2024
Merged

Test Information #1529

merged 1 commit into from
Oct 22, 2024

Conversation

m-ildefons
Copy link
Contributor

Annotate the test information with Rancher/RKE version information. This helps the test report HTML files to be less ambiguous about the configuration under test.

Copy link
Contributor

@albinsun albinsun left a comment

Choose a reason for hiding this comment

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

Rancher part LGTM. Have some comments on Harvester part.

apiclient/rancher_api/api.py Outdated Show resolved Hide resolved
cur = "v8.8.8" if "master" in cur else cur
self._version = parse_version(f"{cur}.99")
except ValueError:
self._version = parse_version(ver)
Copy link
Contributor

Choose a reason for hiding this comment

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

It's better to keep current implementation in try and new one in exception.

try:
    self._version = parse_version('8.8.8' if 'master' in ver else ver)
except:
    #YOUR_NEW_IMPLEMENTATION

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, why?

@m-ildefons
Copy link
Contributor Author

The goal of this PR is to enhance the metadata annotations of the test results and go from this:

Screenshot at 2024-09-17 10-04-48

to this:
Screenshot at 2024-09-17 10-05-02

# XXX: fix master-xxx-head to 8.8.8, need the API fix the problem
self._version = parse_version('8.8.8' if 'master' in ver else ver)

# Rancher versions look like v2.9.2, or v2.9.2-something
Copy link
Member

@lanfon72 lanfon72 Sep 18, 2024

Choose a reason for hiding this comment

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

Although Rancher is not using master-head, we would still need to consider cases like:

  1. v2.9.1-rc6
  2. v2.9-2f9a7509687f559d772be75d61df7f7409803883-head

As the second case would be the latest of v2.9, we need to fill the patch version for it. (to notice that there will not have something like v2.9.1-sha-head)

so, I would suggest that we could update it to something like

try:
# XXX: https://github.com/harvester/harvester/issues/3137
# Fixed as:
# 1. va.b-xxx-head => va.b.99
# 2. master-xxx-head => v8.8.99
cur, _, _ = ver.split('-')
cur = "v8.8" if "master" in cur else cur
self._version = parse_version(f"{cur}.99")
except ValueError:
self._version = parse_version(ver)
# store the raw version returns from `server-version` for reference
self._version.raw = ver
return self._version

which we already implemented in HarvesterAPI.
To notice that Python usually use try-except to control the flow.1

Footnotes

  1. https://devblogs.microsoft.com/python/idiomatic-python-eafp-versus-lbyl/

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That was what I did initially, but @albinsun wasn't happy with it.

Copy link
Contributor

@albinsun albinsun Sep 19, 2024

Choose a reason for hiding this comment

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

I was talking about the order but not drop error handling.
My thought was

  1. Existing implementation works for most cases
    (Except head form like v2.9-2f9a7509687f559d-head)
  2. I thought you are dealing the head form case, so it's natually to suggest
    try:
       # Existing implementation
    except:
       # Dealing exceptions
    

Anyway, per discussed, It's reasonable and OK for me to align with Harvester API side implementation, thx.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think I have a good implementation now. It tries hard to parse the version, it keeps the suffix information for later reference and if all fails, it behaves like the Harvester API implementation.
I noticed that with my version of the pkg_resources library parse_version never raises an exception, but will produce a LegacyVersion object in case it doesn't know how to deal with it:

Python 3.6.15 (default, Sep 23 2021, 15:41:43) [GCC] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pkg_resources import parse_version
>>> parse_version("foobar-noversion")
<LegacyVersion('foobar-noversion')>

Therefore I'm quite sure that the exception case will not raise another error.

Copy link
Contributor

Choose a reason for hiding this comment

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

As I know our daily env. adopts python 3.10 which has different behavior on parse_version

Python 3.10.14 (main, Mar 24 2024, 08:01:04) [GCC] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pkg_resources import parse_version
<stdin>:1: DeprecationWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html
>>> parse_version("foobar-noversion")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/albin/Workspace/albinsun/tests/.tox/py310/lib/python3.10/site-packages/pkg_resources/_vendor/packaging/version.py", line 200, in __init__
    raise InvalidVersion(f"Invalid version: '{version}'")
pkg_resources._vendor.packaging.version.InvalidVersion: Invalid version: 'foobar-noversion'

Copy link
Member

Choose a reason for hiding this comment

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

LegacyVersion had been dropped in pypa/packaging#407

# parse the version name into a Version object if possible
# save the suffixes as one string, e.g.:
# v2.9.2 => <Version('2.9.2')>, suffix = None
# v2.9.2-rc1 => <Version('2.9.2')>, suffix = "rc1"
Copy link
Member

Choose a reason for hiding this comment

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

To notice that the suffix is meaningful for the Version instance to compare with others, for example:
image

so we should only handle the case like v2.9-2f9a7509687f559d772be75d61df7f7409803883-head, as I know, rancher will not use -dev-<date> format, so it is fine to not consider the case.

Copy link
Contributor

@albinsun albinsun left a comment

Choose a reason for hiding this comment

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

LGTM

Annotate the test information with Rancher/RKE version information. This
helps the test report HTML files to be less ambiguous about the
configuration under test.

Signed-off-by: Moritz Röhrich <moritz.rohrich@suse.com>
@m-ildefons
Copy link
Contributor Author

I've reduced this PR to the bare essential, which is to have the raw version string in the test metadata.

@lanfon72 lanfon72 self-requested a review October 22, 2024 17:32
@lanfon72 lanfon72 merged commit 2448a02 into harvester:main Oct 22, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants