Support remote path to identity key in Git deployment strategy

[fjros]

Support remote path to identity key in Git deployment strategy

Description

Add variable ansistrano_git_identity_key_remote_path as an alternative way of indicating the identity key to be used by git commands. Contrary to ansistrano_git_identity_key_path, the new var indicates the absolute path towards a file on the remote server, not the control machine.

Use case

Needed when the control machine does not have local access to deployment keys but they're already available on remote servers by any other means.

Rationale for the use case

A given deployment key can be linked to just one repository on GitHub. Let's say you have n servers with r distinct repositories deployed on each of them. Instead of forcing the control machine to have local access to n*r identity keys, you can provision each server with the r keys it really needs and refer to them from the control machine with a well-known path based on the repo name.

Test

A new test has been added to check that a repo can be deployed when the remote path to the identity key is given. Such test implies:

• An identity key has been added to test/deploy.key
• The test clones a dummy repo that honors such deployment key

[fjros]

@carlosbuenosvinos could you please force the build for this PR? Seems that it faced a connectivity issue. Thanks :)

[carlosbuenosvinos]

First of all, thanks for the contribution. LGTM! However you should point to an existing repo of the ansistrano organization just in case you delete the repo or anything happen. What do you think @ricardclau?

[carlosbuenosvinos]

Added some comments about using trim filter. Take a look.

[fjros]

@carlosbuenosvinos agreed, let me know the new repo when it's available and will point to it.

[OctoPoints-Bot]

We already have a test repo in the organization. Take a look ;) maybe you can use that for your test.

Carlos Buenosvinos @buenosvinos

On 27 Jul 2017, at 13:02, Francisco Ros notifications@github.com wrote:

@carlosbuenosvinos agreed, let me know the new repo when it's available and will point to it.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[fjros]

In that case you must add the deployment key to such repo, otherwise we cannot test this particular use case.

[ricardclau]

I think the test is a bit useless as the testing repos are public, not private This feature should be used for private repos which are the ones needing this key

I also think the git strategy is become way too complex, I cannot think of a better way to implement this but we should refactor it at some point

[fjros]

@ricardclau I have to disagree ;-) In my opinion the test is actually checking what it should. Note that it's using SSH not HTTPS to pull the repo. Hence the referred identity key must have been granted read (or read-write) access on the GitHub repo, otherwise the git command will fail. This is true regardless the repo is public or private (AFAICT).

Just to show my point... If I remove the deployment key from the test repo and run the test:

TASK [local-ansistrano : ANSISTRANO | GIT | Update remote repository using SSH key] ***
fatal: [localhost]: FAILED! => {"changed": false, "cmd": "/usr/bin/git clone --origin origin '' /tmp/git/my-app.com/repo", "failed": true, "msg": "Cloning into '/tmp/git/my-app.com/repo'...\nPermission denied (publickey).\r\nfatal: Could not read from remote repository.\n\nPlease make sure you have the correct access rights\nand the repository exists.", "rc": 128, "stderr": "Cloning into '/tmp/git/my-app.com/repo'...\nPermission denied (publickey).\r\nfatal: Could not read from remote repository.\n\nPlease make sure you have the correct access rights\nand the repository exists.\n", "stdout": "", "stdout_lines": []}

If I add the deployment key to the test repo and run the test:

TASK [local-ansistrano : ANSISTRANO | GIT | Update remote repository using SSH key] ***
changed: [localhost] => {"after": "fdce99d37b445754382f59621560d1a22d9d9832", "before": null, "changed": true, "warnings": []}

[fjros]

@ricardclau Regarding complexity, I tried to make it as simple as possible. In fact the PR only adds one var and one task. But I'll be happy to explore other options if you think of an alternative.

[ricardclau]

Yeah, complexity was not about this PR but also about the other one pending and the amount of hacks needed to support split tree or submodules

And sorry about my misunderstanding on how specific repo keys work. I somehow thought they were valid for all public repos but you proved this is not the case!

Cool, let me add this private key to some of the ansistrano test repos and we will merge this soon

Thanks for the contribution and clarifications!

[fjros]

Great! Thanks a lot Ricard :-)

[ricardclau]

Can you please send me the public key for this private key? We need this to set Github up

Please make sure you don´t use this key pair anywhere else

Also, please note some minor comments

[fjros]

Here you go :-)

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDdmg2m3Au/dz+rTzuv5YhIUeURohekgUHnNdOx7pExf+PsAnihZknlbofg1EDuFboS8oC8m9PNTYKJE+wrn4sBaFKUwWRnkEkfjcVxW5T3af5VKXtKZCVWF2xII2rEoPcvOBhym+93qcsZ/aHKK2QPaYP9o58TWM0phh83kJGQUuHloDUl8YCqfMh+SORb/k1YxkzqEVHAf+ESDpVFg4DbC+TYvQ1XFnOOpIBz/M0LkLtvCdOXDhu2EFQ3gOGS72vzPwukUjVta6vZq0kFk41czG5b98p08FfZNAnivlC0IaCpC+9PWtn+qXztJmNcMnHTOG3knpTvlblBeALSvh4HS5tDqeJ4aDLOWAgv5h2oVavYeyCo6vK94ZgSPcWBFRegjc2y7BrELjp7111koHiq1JpYyOYawNkTbXT0VG5YKxClzvnOe4SIsS/2C67TXvHFMgViumhoUHjFG6aiDkYgv5UVl+owjXby/Im+oExjFe+ke3LL7cgl+TLEmahl5ZDJvd2EdlfBZecsmrMg5XZV4KBgK0VDD46ORHP4m4TyVmP5nBe3oaXqOjg9NWDOk+krYGfMyQi4ZDLySjew8WoKFdCTEJasbtJNmimnSMEX8CkZkdgWXJ7m40oUUlpjYfb84Wbw2GocpHP85AUTk1uJ3yXqLQbKd048BJXNN3oVXw== test@ansistrano.com

[ricardclau]

There is something weird... tests still pass and the key has not been added yet

They should fail now, right?

[fjros]

Oops, didn't expect this :-| AFAIK you can clone a public repo via SSH if you can authenticate on GitHub. I assumed the test machine didn't have any User Key, hence the only way to pull the code was by means of a deployment key. My local environment is just like that, so deployments fail if there's no deployment key.

My guess is that the Travis testing environment employs the User Key of the Ansistrano organization and hence it can clone any public repo. If that's the case (I don't know much about Travis), then the test isn't that useful for the automated build as you suggested initially :). Depending on your local config, it's still valid if you manually run the tests though.

[ricardclau]

Yeah, that would be an explanation, but I don´t know

Anyway, merging this, thanks for the contribution, docs and tests and sorry about the back and forth!

[ricardclau]

Tests were failing when I merged and they went back green once I added the key to the git-test ansistrano repo

So, the test is indeed working as expected (and it fails if the key is wrong).

I don't know what could have happened exactly but maybe your last commit did not trigger a build?

Never mind, back to green, it's all good! Thanks!