Currently working on updateing the Dockerfile for meshery-kuma. I have made adjustments, and would like to test the effectiveness of these adjustements by triggerring the workflow that failed in the main repo (the end goal is to have these tests pass).
This could be as a result of admins placing certain restrictions on the repo, the main goal here is to test whether the changes made to the Dockerfile trigger the Test Kuma Adapter workflow and all cases pass with the updates, (before creating a pull request).
After testing the changes made to the Dockerfile, by pushing the file to the created PR and triggering the test cases, the tests seem to fail at the exit section of the flow, but not much context is given to why the tests exit.
Since a warning was issued regarding a potential incompatibility between kubectl version 1.29.2 and Kubernetes version 1.21.5. I’m also factoring in that perhaps the failing tests might not be connected to the Dockerfile and the base image (at least not the one in this PR)?
I am not sure I am investigating that issue. I was assigned the issue that has to do with applying fetch/rebase to a workflow to ensure that changes are committed successfully.
I already made a PR moments ago.
The other issue I am handling is to provide model components relationship for edge scenarios.
@sandramsc the github action checks for a deployed kuma pod in the kuma namespace at this step . The failure you get at the end exitstatus is in reference to this test. Also the logs suggest that there are no resources in the Kuma namespace
I have a potential debugging point that you could follow and see where they lead you:
the test deploys a kuma adapter pod in meshery namespace called meshery-kuma, is this the container we should be checking for ? Potentially the bigger question is, from the design of the adapters do we expect a meshery-kuma adapter to deploy kuma the actual service mesh in the kuma namespace or deploying the kuma service mesh is a secondary operation once the adapter is installed
