-
Notifications
You must be signed in to change notification settings - Fork 884
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
Reorganize Kubeflow tests #2797
Comments
Let's discuss this in the next kubeflow platform meeting :-) |
@hansinikarunarathne is also working on this and has a draft. Can we maybe merge both issues? |
@juliusvonkohout sounds like a good plan. I can share a few thoughts on where and how I think this should head. We can talk at the next KF Platform/Manifests WG Meeting. |
I think https://docs.google.com/document/d/1FSbGDPko3rZ77oU5F4xxDwGhzgfYbvq5kX-ZciUzaT4/edit?usp=sharing is the document from @hansinikarunarathne |
Reopen after merging #2805 |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
/lifecycle frozen |
Validation Checklist
Version
master
Describe your issue
The tests for the Kubeflow Components are currently placed either in the GitHub Actions Workflow Templates or under the
tests/gh-actions
path, or undercontrib
in an unorganized manner. It's confusing and lacks organization. There should be well-organized place or alignment for the tests. Those should preferably run with a testing framework likepytest
. If we were to improve this situation, we can start implementing a more robust and flexible test framework that can be simply run from GH Actions or in the user development environment.To point a few tests that could be reorganized:
Additionally, some of the components lacks a proper e2e tests. Here is the list of GH Actions that performs sanity tests by just deploying the manifests on the cluster but are not providing any more insights than that:
Additionally, we could start using some nice utilities like
pre-commit
to automatically run some actions like linters, formatters, check if commit is signed and potentially more. Then, such apre-commit
configuration could be used both from the GH Actions and from the Developer Environment. These are the GH Actions that could benefit from this pattern:This was recently touched upon here: 2795#discussion_r1674228094.
Steps to reproduce the issue
N/A
The text was updated successfully, but these errors were encountered: