Best Git strategy for testing different client and server versions

I would like to be able to run integration tests for a Java client/server (using embedded jetty). In addition I would like to be able to mix-and-match different server and client source code versions during the integration testing.

I am wondering what the best git or maven version strategy to accomplish this:

  1. Using the same git repository for the client and the server, it would be difficult to checkout code of various server versions and test it against code of various client versions.

  2. Using separate git repositories (1st repository with client src and integration tests, 2nd repository with server src) – It would also require to checkout both repositories to run the integration tests, and assume relative paths between them.

  3. Testing the client src code only against maven-version server WAR, may result in honest mistakes of developers running tests against a server WAR that does not match the checked-out server source code.

  • Line history viewer - Git
  • What is best practice for keeping secrets out of a git repository?
  • Possibilities of implementing a git server
  • EGit out of sync
  • Check version on remote ftp?
  • Are there any free version control hosting applications I can host myself?
  • Looking for a way to store versions in a binary compiled from git repo
  • Software version numbering with GIT
  • 2 Solutions collect form web for “Best Git strategy for testing different client and server versions”

    I suggest keeping the process simple, as you have enough variables going on already without introducing potential git management issues. To that end, I would avoid submodules. I would instead give the developers clear pairings of branches/tags to test for both the client and server repos in your testing matrix.

    Use tags so you can more easily reuse and repeat the same tests in your matrix again in the future, especially after bugs have been fixed from the first round.

    In short, I recommend your solution #2. The relative paths assumption is preferable to the potential confusion introduced by submodules.

    I’ll point out a third challenge: The integration tests may have bugs, so you might wish to control the test version independently as well.

    I’ve used git’s submodules feature to coordinate multiple repositories. Create a new repository that will contain references to both the client repo and the server repo. You can place a basic test driver in this parent repo as well.

    When a new developer joins the team, they can clone this parent repo, then run git submodule update --init to clone the client and server submodules. That way they’ll have any relative paths set up the same way as everyone else.

    However, I don’t like letting, say, the client repo assume that the server is at ../server/. So the way I’ve handled this is to let the parent repo pass any needed paths to the submodule. For example, you could have a test.sh in the parent repo that runs

    make -C client SERVER_PATH=$(pwd)/server test
    

    In your case, you could also place all the test code in the parent repo. Then it can safely assume relative paths to the submodules.

    An interesting side benefit of this arrangement: You can create git commits that record specific combinations of versions, because the version that’s checked out in the submodule is recorded when you commit in the parent repo. You might use that to create a branch or a collection of tags for version combinations that have passed your tests.

    Git Baby is a git and github fan, let's start git clone.