bisakhmondal commented on issue #3601: URL: https://github.com/apache/apisix/issues/3601#issuecomment-946890377
After having a discussion with @spacewander, there is something, I'd like to point out here. At present we are testing the gRPC plugin through an upstream server written in Go ([api7/grpc_server_example](https://github.com/api7/grpc_server_example)) and a shell script to test the expected behaviour. But the thing is the CI setup for this is not a good approach for few reasons - First, we are pulling the release candidate binary that runs the server and then again we are cloning the repository to get the proto file. https://github.com/apache/apisix/blob/50fed630823bb3c562f411d7cb5f5d38218348fb/ci/linux_openresty_common_runner.sh#L47-L58 So whenever we want to 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 api7/grpc_server_example 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. Thanks! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
