Generally this was written for deployment purposes.
Just curious on your use case:
(A) So in your organization the repo is locked down?
(B) Or you are automating developer machine setups?
I can see both being useful, but I’m guessing A, right?
Correct.
(If you are pulling off a repo that is non-secured and it is just for
deployment purposes, I’d probably just clone read only)
Which reminds me that the “correct” way to do this is either to allow
authentication-less read-only clones, or to set up read-only https
access to the repos with basic auth.
Which of course means scratch all this.
I’m going to add some cool tricks to pass environment variables to
/everything/ really soon, and this may be exactly what you want.
Well, I certainly want that generally, but I imagine in this scenario,
even if I do `GIT_SSH=“ssh -i ” or somesuch, I’ve still got to
provide a password to unlock the keyfile, and doing that programatically
seems to remain an issue.
Which brings to a couple of ancillary questions, actually:
Is there any consensus on requiring target-host-side software in
modules? My (non-)issue could be solved by the use of expect, or
perhaps sshpass, on the target-side. I’d imagine that those kind of
things ought to be kept out of the included modules, though, correct?
Barring inevitabilities like the git module needing git, obviously.
On that note, what about dependencies on python modules outside of
the standard library? I assume it’s preferred if the module is
self-contained, no?
And one final question, if you don’t mind: has any thought been put into
a means to pass requests for input on the target-side (i.e., ssh asking
for a password) back to the user for interactive input? I should probably
see how the ssh-askpass stuff is implemented.
Can you hold off a few days maybe? It would allow for GIT_SSH
trivially, without modifying the module.
I certainly can, especially because I’ve likely found a way around the
issue.
Also, just a quick thanks for ansible (and your work on cobbler, also); I
work in a shop particularly fond of leaving repetitive tasks unautomated,
and the simplicity of ansible’s model is just about the only chance I have
of rectifying that. Keep up the excellent work!