State git.latest doesn't use the identity file specified

[multani]

When running a git.latest state with a dedicated identity file specified, it doesn't use the identity file at some point and ask for the password instead:

[INFO    ] Executing state file.managed for /home/multani/.ssh/salt-deploy
[INFO    ] File /home/multani/.ssh/salt-deploy is in the correct state
[INFO    ] Executing state git.latest for git@git.example.org:multani/linux-config.git
[INFO    ] Executing command 'git rev-parse HEAD' as user 'multani' in directory '/home/multani/linux-config'
[INFO    ] Executing command 'git branch --list | grep "^*\\ " | cut -d " " -f 2 | grep -v "(detached"' as user 'multani' in directory '/home/multani/linux-config'
[INFO    ] Executing command 'git ls-remote -h git@git.example.org:multani/linux-config.git master | cut -f 1' as user 'multani' in directory '/home/multani/linux-config'
git@git.example.org's password:
git@git.example.org's password:
git@git.example.org's password:
[INFO    ] Executing command 'git remote show -n origin' as user 'multani' in directory '/home/multani/linux-config'
[INFO    ] Executing command 'git rev-parse master' as user 'multani' in directory '/home/multani/linux-config'
[INFO    ] Executing command 'git checkout  master ' as user 'multani' in directory '/home/multani/linux-config'
[INFO    ] Executing command 'git symbolic-ref -q HEAD > /dev/null' as user 'multani' in directory '/home/multani/linux-config'
[INFO    ] Executing command 'git pull ' as user 'multani' in directory '/home/multani/linux-config'
[INFO    ] Executing command 'git rev-parse HEAD' as user 'multani' in directory '/home/multani/linux-config'
[INFO    ] No changes made for git@git.example.org:multani/linux-config.git

This happens here when running the state from the minion using salt-call state.highstate and doesn't happen when running the highstate from the master directly.

I have this problem since I upgraded to 0.17.1, it didn't show up on the 0.16.4 I was using before.

It seems it happens only when running git ls-remote which, from https://github.com/saltstack/salt/blob/develop/salt/states/git.py#L36, seems to be the only Git function which is called outside of the Salt's Git module, which correctly uses the identity file passed to the state.

[basepi]

Thanks for finding this, and figuring out where it's calling for the password. Looks like this ls-remote call is new since 0.16.4, and the author obviously just didn't handle keys properly. We'll get this fixed.

[cachedout]

This should already be fixed by 7d0c0a3. @multani could you please try again with the latest code from the develop branch and see if your issue is resolved? Thanks!

[multani]

@cachedout I tested the fix and the issue is still valid.

I think it comes down to two problems :

• first, the key I'm using as a "special" name. I guess it wasn't very clear, but as you can see in the output of salt-call state.highstate I posted in the original message:

[INFO    ] Executing state file.managed for /home/multani/.ssh/salt-deploy
[INFO    ] File /home/multani/.ssh/salt-deploy is in the correct state

So the SSH key I'm using is in ~/.ssh/salt-deploy, which doesn't seem to be picked up by Git or SSH if I don't specify it explicitly:

$ git fetch -v
git@git.example.org's password: ^C
$
$ ln -s ~/.ssh/salt-deploy ~/.ssh/id_rsa
$ git fetch -v
From git.example.org:multani/linux-config
 = [up to date]      master     -> origin/master
$

It means that switching to the right user, as 7d0c0a3 does, is not sufficient.

• which brings us to the second problem, which is that git ls-remote, as called currently by Salt, doesn't use the SSH key specified to the state whereas the other Git commands do. For example, salt.modules.git.pull calls salt.modules.git._git_run with the specified identity, which creates a special GIT_SSH environment variable with the right thing to do to connect using SSH. ls-remote doesn't do that for the moment.

I will try to propose a patch someday before next week...