-
Notifications
You must be signed in to change notification settings - Fork 32
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
tests: test CRD versions #1317
base: main
Are you sure you want to change the base?
tests: test CRD versions #1317
Conversation
943710d
to
26cc904
Compare
Add test which checks if the CRD versions defined in the cluster match the versions in the subcharts in the git repo. This test ensures that the subcharts in the release version don't unexpectedly change their API versions within a minor Harvester release. To implement this test, additional infrastructure for the Kubernetes API has been added. fixes: harvester#1314 Signed-off-by: Moritz Röhrich <[email protected]>
26cc904
to
33c5419
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, the library apiclient
is focusing for Harvester and related endpoint, we don't and will not have plan to implement kube APIs, as it already have many other libs does.
and as Albin's snippets, it shows we can simply get those CRD info from bash, so I would prefer use that version rather than create a new API set.
It would be more readable and fit our manual test steps.
and I don't think we need to verify those CRDs every time, usually we will only verify them after the cluster upgraded into new version, so we will not place then in apis
.
assert code == 200 | ||
assert data.get("value") is not None | ||
|
||
yield semver.VersionInfo.parse(data.get("value").lstrip("v")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we already have apiclient.cluster_version
to expose the cluster's version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The apiclient.cluster_version
returns a pkg_resources.Version
object, but my tests are using the semver
library to parse versioning information.
The semver
library has several advantages. One being that it isn't in the process of being deprecated. Another advantage is that it has good documentation and deals with a lot of different operations on version information better. Third, the pkg_resources
library is supposed to deal with python-packages and not generic version information. This is a difference in so far as python packages have specific requirements on the format of the version string that we don't adhere to with Harvester
Test target and classification are important, we should not mix different purpose test code. Or we can have this automation in another folder or something thus not break test organization? How do you guys think? |
Well, it does not. There's also a Rancher API client part in it.
Please no. We have a test suite, let's not add a second test suite.
I see your point, but I don't see where else in the test suite an appropriate place would be. Maybe we should create a separate directory for upgrade tests under |
Signed-off-by: Moritz Röhrich <[email protected]>
|
Add test which checks if the CRD versions defined in the cluster match the versions in the subcharts in the git repo.
This test ensures that the subcharts in the release version don't unexpectedly change their API versions within a minor Harvester release.
To implement this test, additional infrastructure for the Kubernetes API has been added.
fixes: #1314