Hi Community, At present we are testing the gRPC plugin through an upstream server written in Go [1] and a shell script to test the expected behaviour. But the thing is, the way we are setting up the test environment is not a good approach as
First, we are fetching the release candidate binary that runs the server and then again at the second stage we are cloning the repository to get the proto file. [2] Also whenever we make any changes in the upstream gRPC example server repo, we have to explicitly release a new binary just for the sake of satisfying this approach which is manual and not at all developer-friendly. Proposed Solution: One easy solution could be cloning the master branch every time we run the CI, but it could introduce instability in the CIs as maybe at some point of time the master is not fully ready or broken. I think we could leverage the benefits of `git submodules` here by putting the [1] project into a suitable subdirectory. In this way, we will have explicit control over the state of the submodule on which we are running the tests because the submodule HEAD itself points to a commit hash. And whenever we update the upstream, we just have to move the submodule HEAD to that particular commit hash via a `git pull` or something like that. In this approach, the upstream project will be compiled inside the CI and that might cost a few seconds for dependency fetching and compilation. But considering the very small size of the project, I think this is okay. Let me know what do you think. Thanks! Best Regards, Bisakh (https://github.com/bisakhmondal) [1] : https://github.com/api7/grpc_server_example [2] : https://github.com/apache/apisix/blob/50fed630823bb3c562f411d7cb5f5d38218348fb/ci/linux_openresty_common_runner.sh#L47-L58
