@hershd23 as Lee pointed out, nektos/act exists but even I haven’t had much success with it. It is also inconvenient when you use it with GH actions that depend on Minikube or Kind as Kubernetes clusters, which themselves depend on docker.
My personal workflow goes like: fork the action’s repo, make your branch, keep doing your changes and pushing them to your branch. For testing your changes, you can either make a workflow in the fork itself which uses your action and runs on every commit you push or you can have a separate repo for testing where you’ll create a workflow referencing your action and trigger it manually each time you want to test your changes.
Was revisiting the discuss forum and stumbled upon this question again. Now that I have tested out a few meshery workflows I have just one thing to add to @DelusionalOptimist’s correct answer.
For an action to get registered into Github actions it must be present on the master. Once it is on master we can reference any branch that we want the workflow in xyz branch to run. That implies
If you are editing an already existing workflow, no extra work to be done, your local fork would have the workflow provided you have the latest pull on master of your local fork.
If creating a new workflow in a new branch merge the branch with master and push to your local fork when you want to run the workflow. Post which the workflow will be registered for your use.