Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
t/t-batch-transfer.sh: test multiple SSH uploads
In commit 691de51 of PR git-lfs#4446 we added the "batch transfers with ssh endpoint (git-lfs-transfer)" test to our t/t-batch-transfer.sh test script in order to validate that the new SSH object transfer protocol for Git LFS was operating as expected. This test only creates a single test object, and so does not cause the Git LFS client to establish multiple SSH connections during the batch object transfer phase. For this reason, no SSH connections are started with the ControlMaster option set to "no". As described in a prior commit in this PR, our lfs-ssh-echo test utility program had a bug which prevented it from accepting SSH connections with the ControlMaster option set to "no", so the "batch transfers with ssh endpoint (git-lfs-transfer)" test would have failed if it tried to push more than a single object. Such a test would also fail if it tried to fetch more than a single object, due to the bug described in git-lfs#5880. Specifically, we returned a nil from the Connection() method of the SSHTransfer structure in our "ssh" package when we had closed all the SSH connections, but then sometimes tried to reference that nil pointer in the batchInternal() method of the SSHBatchClient structure in the "tq" package, causing a Go panic condition. In prior commits in this PR we resolved these problems, both the bug in the lfs-ssh-echo test utility and the bad return value from the Connection() method of the SSHTransfer structure in the Git LFS client code. In the case of the latter issue, we adjusted the Connection() method to return a non-nil error when the requested connection number exceeds the maximum number of permitted SSH connections, which also covers the case where all the connections have already been closed. Therefore we can now add additional tests of the SSH object transfer protocol which push multiple objects and then fetch them. In these tests we use the new assert_remote_object() assertion function that we added in a prior commit in this PR to confirm that the objects we push are all written to the "remote" repository. As well, we check that the expected number of SSH connections are reported in the trace logs from both the push and clone operations, and that some connections are made with the ControlMaster option set to "no" as well as "yes". The first of our new tests leaves the maximum number of concurrent object transfers set to the default value of 8, so that all three of the objects we create in the test are pushed or fetched in the same batch. This requires that the Git LFS client establish three separate SSH connections, two of which should have the ControlMaster option set to "no", and the first of which should have the option set to "yes". The second of our new tests sets the maximum number of concurrent transfers to two, so we expect to see only two SSH connections established, the first of which should have the ControlMaster option set to "yes". Since there are only two concurrent connections, we can assume the third object was transferred in a second batch. (Note that the Git LFS client, at present, always creates an extra SSH connection with the ControlMaster option set to "yes" when pushing objects over the SSH object transfer protocol. It uses this extra connection exclusively to perform locking commands. Our tests therefore expect this extra connection to be reported in the push trace logs, and we include comments to explain why the expected connection totals are one higher than might otherwise be the case.) Next, we expand the existing "batch transfers with ssh endpoint (git-lfs-transfer)" test to perform the same set of checks as our new tests, bringing the tests into close alignment with each other. We again use the assert_remote_object() function to confirm that the single object pushed in this test is written to the "remote" repository. We also check that only a single SSH connection is reported in the trace logs (plus the extra one used for locking commands during the push operation). Finally, we make a few small adjustments to other tests in the same test script, removing some unnecessary redirections of stderr, and adding one extra check to our "batch transfers with ssh endpoint (git-lfs-authenticate)" test which just confirms that an object was successfully pushed over HTTP to our lfstest-gitserver test helper program, following an initial authorization handshake over SSH.
- Loading branch information