Agree, there are other external dependencies in the repo that can be managed with git submodule feature as well. I would love to see this change.
Leslie Tsang leslie.ts...@icloud.com > On 20 Oct 2021, at 12:35 AM, Bisakh Mondal <bisakhmonda...@gmail.com> wrote: > > 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
