Workflows not triggered - Meshery Kuma

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).


  • fork repo
  • create new remote & local branch
  • make changes
  • push to remote branch
  • expected Test Kuma Adapter workflow to be triggered


  • the events drop down tab under Test Kuma Adapter does not display any events.
  • changing to my branch were the changes have been made displays a no results match your search message


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).

I see that the tests are triggered once a Pull Request is made, but ideally would be better to have these checked before.

Error log from Test Kuma Adapter after recent Dockerfile changes.


Some sources say that it could be an internet connectivity issue?


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)?

@Daniel.Kiptoon, you might like to offer insight here…

@Samuel.Nwanwobi, if memory serves, this might be an item that you’re investigating…

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.

1 Like

@Samuel.Nwanwobi oh, gotcha. Sounds real good.

@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

1 Like

I will keep the points above in mind as I investigate further, thank you so far @Daniel.Kiptoon