Thanks. It would be nice to have a test for this, I guess it is doable relying on localhost only.

Thanks. It would be nice to have a test for this, I guess it is doable relying on localhost only.

I was looking over the testsuite and ran them all locally. I don't actually see anywhere where a remote crate is actually tested. I noticed there are "remote" tests but they all reference a local git repository; I don't see anywhere where a remote git repository is actually used in a test.

Am I missing something here?

My strategy for testing was to just run all the tests that use http to access remote git repositories to also use ssh, effectively running them twice. It's easy to do this using git's insteadOf option. For example, you can do something like:

git config --global url."https://<username>:<password>@<server>.com/".insteadOf "git@<server>.com:"

to force https and the opposite to force ssh. That way I don't need to actually write any tests: just run the existing tests twice using different git configurations. This is actually how we did it in our company too when certain machines aren't setup for ssh (e.g., the CI environment which prefers https) or aren't setup for https (e.g., locally where running ssh-agent is preferred).

I wasn't very clear. Current tests don't use git remotes, indexes are configured as local folders, but for a couple of exceptions. What I envision is a dedicated test test in which a local indes is added using ssh through localhost, without special git configuration. I can do it at some point if nobody beats me to it.

I wasn't very clear. Current tests don't use git remotes, indexes are configured as local folders, but for a couple of exceptions. What I envision is a dedicated test test in which a local indes is added using ssh through localhost, without special git configuration. I can do it at some point if nobody beats me to it.

I wrote a quick test using the libhello crate and test index you have already on github. I'll push it shortly for you to check out and see if it is sufficient. I'm running into an issue with the test now when I try to pin a crate using ssh: Unable to determine compiler version.

I'll sort that out then update this pull request.

You need a compiler external definition in your indexes and it seems you don't have one. Check the testsuite/skels/no-index/test.yaml example for an index you can use in parallel with the one you're testing.

You need a compiler external definition in your indexes and it seems you don't have one. Check the testsuite/skels/no-index/test.yaml example for an index you can use in parallel with the one you're testing.

Done. The test works locally ... we'll see how it does here. Ideally this test is run in a disposable environment (e.g., docker container) so that it doesn't mess with anyones host machines. In the pipeline it's fine.

Update: it doesn't work here :(. I'm not as familiar with GitHub actions (we use GitLab). Is there some existing ssh infrastructure in the GitHub actions or in the repository that needs to be setup so ssh keys can work?

It's a good starting point but, as you say, better not to mess with the user ~/.ssh. I'll dockerize it.

It's a good starting point but, as you say, better not to mess with the user ~/.ssh. I'll dockerize it.

Ok - you'll see there is also an issue with the ssh keys here too. I am not familiar with how GitHub manages ssh keys in the actions (only used GitLab).

There's also a limitation in this PR which is that it only will work for git@ remotes, which is kind of an assumption. I'm adding a more general solution.

Awesome - thanks!