Thanks goes to Chris Blossom who did most of the research for this.
https://github.com/ansible/ansible/commit/18050d50ecf94df95464a560d66d5e8d820ac52c
sshopts
Creates a wrapper script and exports the path as GIT_SSH which
git then automatically uses to override ssh arguments. An
example value could be “-o StrictHostKeyChecking=no”
keyfile
Uses the same wrapper method as sshopts to pass “-i ”
to the ssh arguments used by git
Test away!
A few quick updates…
Per argument conventions, these will be “key_file” and “ssh_opts” soon.
(Testing is welcome!)
Basically using this you will no longer need to know about tricks where you have to use the “environment” keyword to set “GIT_SSH” as an environment variable.
In the past, people have typically had to forward SSH keys, and this means that it’s easier to use a different key, such as a GitHub deploy key, rather than yours, if you didn’t know the above tricks.
The accept_hostkeys argument is also new in 1.5, which solves the problem of having to manually add a git server’s hostkey to known_hosts prior to using git.
All of this combined together, the git module should be a TON more friendly in 1.5!
The accept_hostkey fails if $HOME/.ssh doesn’t already exist.
Please file a bug on github or submit a pull request.
I'm new to ansible development, but not test cases, or git. I've
already been installing ansible by updating my git clone, and building a fresh deb.
Would such a pull request want a test case? I haven't look at all at
how ansible would want that.
The basic scenario is that my remote_user is root, I'm connecting to a
freshly cloned opennebula centos machine, that has nothing on it, except that it allows remote root login. There is no .ssh folder, and I use no key. Later on, when I run git to check out a repo, it tries to create /root/.ssh/authorized_keys, but the folder doesn't exist.
I have my own rules that create .ssh and .ssh/authoried_keys, as
separate tasks, so I'm not held up; I was just trying to use the new
feature.
Tests would be really nice, but I’m not sure if we have a good pattern within the existing unit tests to accommodate this situation.
If you can write something up, I would certainly review it and try it out.
BTW, a bug was created this morning for the issue: https://github.com/ansible/ansible/issues/5750
As for tests, I have a complete test system for the internal backup tool I've written and used at $work. I basically start up a user-mode-linux instance, then mount hostfs and overlayfs, so that I can run things as root, it has no outbound network, I then start up a dummy sshd, create a dummy non-root user, then rsync/ssh to test parts of the backup tool.
I had this fake-linux wrapper semi-isolated, but never actually released it. I wonder if it would help for ansible.