Git accept_hostkey submodule fix proposal

So working on fixing a little issue where accept_hostkey in the git module doesn’t take into account submodule remotes with different urls. Thus ansible hangs waiting for user to accept the hostkey so it fails when recursion and accept_hostkey are true. There doesn’t seem to be a way to simply clone a single file from a git server (thought about just cloning .gitmodule and parsing it). What I’m thinking may be the only option is to download the repo into say /tmp, parsing the .gitmodule dir to get the urls, removing the clone from tmp and thats it. Seems a bit excessive. Thoughts?

“So working on fixing a little issue where accept_hostkey in the git module doesn’t take into account submodule remotes with different urls.”

Can you share an example of what this might look like?

This proposed fix seems a bit heavyweight and I’m not sure it’s required – might be a workaround available, but I need to understand the use case a little better first.

Right, so imagine if you have your base project stored on GitHub and within that project you have submodules stored on bitbucket.

Assume that neither hostkey has been added to known_hosts

When running a playbook that uses the git module with both recursion and accept_host_key set to true/yes the playbook ran via CLI adds the GH but still prompts for the BB hostkey acceptance/rejection. Within ansible-tower this has the effect of causing the playbook to hang as it is waiting for user input.

Another solution which is more lightweight and less repetitive I thought of is that when recursion and accept_hostkey are true to then let the module run as if recursion was not specified and after the base repo has been cloned to then parse .gitmodules, add the keys and execute ‘git submodule update --init --recursive’ to then add the submodules.

Ah, got it – and interesting – haven’t seen that done before and I suspect it’s a rare case. Thanks for the explanation!

What I would suggest is having a step in the playbook before the git call that makes sure the host keys for github and bitbucket are both present. This could be lineinfile for instance.

I’d prefer that from the logic getting somewhat overcomplicated for an edge case that is unlikely to occur once in a thousand use cases – I’m sympathetic, but that seems to be the better way to go from a maintainability perspective.